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SECTION  1 


INTRODUCTION 


This  document  describes  the  structure  of  the  data  base  used  by 
the  JAMPS  program  to  aid  in  the  preparation  of  JINTACCS  messages. 

In  addition,  the  sources  of  data  and  the  procedures  to  be  followed 
to  create,  modify  and  maintain  this  data  base  are  provided. 

The  understanding  and  use  of  the  material  and  procedures  pro¬ 
vided  in  this  document  requires  no  extensive  knowledge  of  computers, 
electronics  or  programming  techniques.  A  familiarity  with  JINTACCS 
is  assumed,  and  the  ability  to  use  a  text  editor,  particularly  a 
full-screen  editor,  is  necessary  in  order  to  make  revisions  to  the 
data  base. 

The  purpose  of  JINTACCS  is  to  increase  the  operational  effec¬ 
tiveness  of  the  services'  tactical  command  and  control  operational 
systems  and  facilities  used  in  support  of  joint  ground  and  amphib¬ 
ious  military  operations  through  the  1980's.  As  a  part  of  this 
objective,  JINTACCS  is  developing  standard  messages  and  a  common 
message  language  to  facilitate  the  exchange  and  use  of  information 
among  the  JINTACCS  affected  systems  and  facilities.  This  exchange 
of  information  via  a  common  language  is  not  limited  to  facilities 
within  a  specific  service  organization,  but  was  developed  primarily 
for  the  exchange  between  the  different  services  and  allies  such  as 
the  NATO  forces.  Each  JINTACCS  message  type  Is  structured  to  pro¬ 
vide  a  means  of  modularizing  the  multitude  of  Information  types  and 
values  which  are  permissible.  In  this  way,  information  required  by 
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many  different  message  types  shall  be  treated  identically  In  all 
uses.  For  example,  all  messages  containing  a  field  In  which  to 
specify  the  time  of  an  activity  (i.e.,  C0143  009)  would  use  a  common 
definition.  This  field's  definition  would  provide  the  order  of  the 
components  (day,  hour,  minute  and  time  zone),  the  size  or  length  of 
each  subfield  (i.e.,  two  numeric  characters  for  the  day,  hour  and 
minute),  and  the  set  of  values  th'f  is  permissible  for  each  sub¬ 
field  (i.e.,  day  is  a  numerical  value  between  1  and  31).  In  this 
manner,  the  interpretation  of  the  contents  of  all  fields  is 
standardized. 

The  overall  structure  of  the  JINTACCS  message  is  a  hierarchical 
system,  with  message  types  occupying  the  uppermost  level.  For  con¬ 
venience  only,  the  set  of  JINTACCS  messages  has  been  divided  into 
five  classes;  Air  Operations,  Operations  Control,  Intelligence,  Fire 
Support  and  Amphibious.  At  the  message  level,  the  data  content  is 
established  by  the  assignment  of  Keyword  Data  Sets  (KDS's)  to  a  mes¬ 
sage.  A  keyword  data  set  is  a  logical  collection  of  related  items 
referred  to  as  fields.  For  example,  MSGID  is  the  identity  of  the 
KDS  that  is  required  in  every  message.  This  KDS  is  composed  of  six 
fields  which  are  Message  Type,  Originator,  Serial  Number,  Month, 
Qualifier,  and  Serial  Number  of  Qualifier.  The  hierarchical  struc¬ 
ture  of  JINTACCS  is  shown  in  figure  1.  In  this  figure,  the  top,  or 
uppermost  level,  shows  the  message  itself,  and  the  next  lower  level 
is  the  set  of  keyword  data  sets  which  completely  define  the  message. 
The  level  below  the  keyword  data  sets  are  the  fields  which  complete¬ 
ly  define  the  KDS's.  In  the  same  way  that  keyword  data  sets  may  be 
used  in  several  different  messages,  a  particular  field  in  one  KDS 
can  also  be  a  field  in  several  different  KDS's. 

There  are  three  distinct  classes  of  KDS's;  linear  sets,  colum¬ 
nar  sets  and  free  text  sets.  A  ffee  text  set  is  an  unformatted  text 
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statement  of  variable  length.  JINTACCS  has  three  such  KDS's;  RMKS, 
AMPN,  and  NARR.  All  other  KDS's  are  either  linear  or  columnar 
types.  These  two  types  can  be  distinguished  from  each  other  by  the 
naming  convention  used.  All  columnar  KDS  names  begin  with  a  number 
(i.e.,  6BASIC),  while  linear  KDS  names  are  all  alphabetic  (such  as 
MSGID).  In  messages,  columnar  KDS's  allow  data  to  appear  in  a 
message  in  tabular  or  columnar  fashion.  In  addition,  a  heading  is 
associated  with  each  columnar  set  which  provides  a  name  or  an  Iden¬ 
tification  for  each  field  or  column  within  the  KDS.  An  example  of 
this  data  structure  is  shown  in  figure  2.  In  this  figure,  the  area 
printed  in  boldface  is  KDS  CANX,  which  consists  of  four  fields  of 
data  or  information.  In  this  example,  the  first  field  has  the  field 
descriptor  MSG-TITLE.  The  outlined  area  in  this  figure  is  an 
example  of  a  columnar  KDS.  The  first  line  of  this  example  Is  the 
associated  heading  for  the  KDS.  Under  each  entry  of  the  heading  can 
be  seen  the  entered  data  items.  Several  lines  of  data  appear  under 
this  common  heading,  which  is  allowed  under  JINTACCS  rules.  KDS's 
and  the  fields  which  make  up  a  KDS  can  be  designated  as  repeatable, 
which  allows  several  sets  of  data  to  appear  under  a  common  heading, 
as  shown  in  the  example.  In  addition  to  the  repeat  option,  a  KDS, 
or  a  field  within  a  KDS,  can  be  designated  either  optional  or 
mandatory. 

At  the  level  below  KDS  fields  are  the  two  types  of  data  ele¬ 
ments:  elemental  or  chain.  An  elemental  data  Item  consists  of  a 
single,  standalone  piece  of  information.  In  cases  where  the  ele¬ 
mental  Item  can  be  divided  into  two  or  more  logically  related  parts, 
a  chain  element  can  be  defined.  For  example,  If,  at  the  element 
level,  the  item  "TIME"  Is  defined,  it  can  be  further  subdivided  Into 
two  subitems:  hours  and  minutes.  The  element  "TIME"  could  then  be  a 
chained  element  and  would  be  so  Identified  by  a  "C"  prefixed  to  its 
identity,  as  opposed  to  an  "E"  prefix  for  an  elemental -type  Item. 
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Figure  2.  Typical  JAMPS  Display 


This  chain  would  then  be  defined  as  consisting  of  two  E-type  ele¬ 
ments:  one  for  hours  and  the  other  for  minutes. 

At  the  elemental  level,  items  are  referred  to  as  Data  Field 
Identifiers  (DFI)  and  Data  Use  Identifiers  (DUI).  Each  Identifier 
has  an  identifying  numerical  value.  A  Droper  name  of  an  item  at  the 
lowest  level  of  this  structure  consists  of  the  prefix  letter,  fol¬ 
lowed  by  a  four-digit  number,  the  OFI,  and  ending  with  a  three-digit 
number,  the  DUI.  If  two  or  more  DFI's  are  logically  related,  such 
as  quantity  destroyed  (DFI /DUI  E0031  003),  and  quantity  damaged 
( DFI /DUI  E003I  004),  they  will  have  the  same  DFI  number,  but  unique 
DUI's,  as  sdown  by  the  examples. 
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SECTION  2 


SOURCE  FILES 


In  order  to  aid  operators  in  creating  JINTACCS  messages,  the 
JAMPS  program  makes  use  of  several  files.  These  files  are  struc¬ 
tured  in  a  hierarchical  system  similar  to  the  JINTACCS  structure. 
This  section  will  discuss  the  format  and  contents  of  these  files. 

At  the  topmost  level  are  the  message  files  which  provide  a  key 
to  the  contents  and  format  of  each  message.  The  message  Index  pro¬ 
vides  a  linkage  to  the  messages  to  be  used  during  the  final  data 
base  cross  check.  The  message  file,  produced  by  the  catnsg  program, 
provides  the  descriptive  information  and  format  of  each  message. 
Related  directly  to  the  message  files  at  the  next  lower  level  are 
the  two  KOS  files:  the  KOS  index  file  and  KDS  data  file.  The  KDS 
index  file  links  references  In  the  message  files  to  the  proper  loca¬ 
tion  in  the  KOS  data  files.  The  KOS  data  file  supplies  the  contents 
and  format  of  each  KOS. 

The  lowest  level  contains  the  elemental  data  In  three  files; 
the  DFI/OUI  file,  the  field  descriptor/field  header  file  and  the 
codes  file.  The  DFI  number  itself  Is  used  as  an  index  for  the  KDS 
file  to  locate  data  at  the  elemental  level.  The  DFI/DU1  file  de¬ 
fines  the  field  size  and  content  type  such  as  numeric  or  alphabetic, 
while  the  field  descriptor/field  header  file  contains  their  descrip¬ 
tions.  The  codes  file  provides  all  valid  character  codes  for  each 
data  element. 
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2.1  Message  Files 


There  are  three  types  of  general  source  files  used  to  contain 
the  data  required  for  building  and  validating  the  messages.  These 
files  contain  information  about  all  the  messages  in  general,  and 
define  the  elementary  parts  which  comprise  the  messages.  Two  of 
these  types  of  general  source  files  are  msgindex,  and  the  catmsg 
file. 


In  addition  to  these  two  types,  there  are  individual  files  for 
each  JINTACCS  message  in  the  JAMPS  system.  Each  file  specifically 
defines  the  given  message,  its  format  and  its  component  parts.  A 
list  of  the  messages  implemented  for  the  Air  Force  Participating 
Test  Unit  (PTU)  Certification  test  appears  in  table  1.  This  list 
contains  only  the  Air  Ops  messages  and  will  be  added  to  in  the 
future. 


2.1.1  Message  Index  (msgindex)  File 


The  msgindex  file,  a  portion  of  which  is  pictured  in  figure  3, 
is  a  list  of  all  the  messages  and  their  respective  index  numbers. 

The  very  first  entry  to  the  msgindex  file  Is  the  token  ".msgindex", 
which  serves  to  identify  the  file  as  being  the  message  Index  file. 

A  token  is  a  signal  to  the  processing  routine  to  begin  or  alter 
processing,  depending  on  the  value  of  the  token.  In  the  JAMPS  data 
base,  tokens  are  generally  designated  by  a  leading  period.  The 
format  of  the  file  is  the  message  number,  followed  by  the  short 
message  name  (or  message  acronym)  and  the  Index  number  which  has 
been  assigned  to  that  message.  The  order  of  the  messages  In  the 
list  Is  not  Important.  A  new  message  may  be  added  to  the  end  of  the 
list  with  the  next  sequential  index  number  being  assigned  to  that 
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Table  1 


Message  Files 


Message  Number 

Message  File  Name 

B704 

abchange 

B705 

acsamstat 

E710 

ai rdefcom 

E715 

ai rdefwarn 

B703 

a i revent 

F541 

aknldq 

F631 

almsnscd 

A770 

al  ord 

D630 

al  req 

A650 

aporal ot 

F654 

crossconf 

A653 

crossdat 

F750 

desiqarea 

F751 

ecmdat 

A651 

employaloc 

B711 

endsts 

F632 

fltcontinfo 

F754 

f Itpln 

F636 

heloalconf 

A635 

heloaldat 

E706 

i nithand 

0660 

jai rreq 

0665 

jairsupreq 

0200 

jcasintreq 

0666 

jescreq 

8750 

j  inf  It 

B702 

jlnchrep 

0667 

jrecreq 

0669 

jsarreq 

0668 

jsupreq 

C001 

msgchangerep 

E707 

rechand 

F625 

reqconf 

A661 

reqstatask 

C482 

sarir 

C420 

sarsit 

A652 

sortalot 

A690 

tacopdat 

A691 

techopdat 

F752 

trkman 

F753 

trkrep 

•msgindex 

;  field  order  is  as  follows: 

;  message  number 

;  short  message  name 

;  message  index  number 

;  edition  number  (blank  will  be  interpreted  as  edition  0) 


d669,jsarreq. 

1 

a650,aporalot. 

2 

a653,crossdat. 

3 

a661,reqstatask, 

4 

a690,tacopdat. 

5 

a691,techopdat, 

6 

a770,a1ord. 

7 

b702,jlnchrep. 

8 

b703,airevent. 

9 

b704,ahchange, 

• 

10 

• 

• 

f636  ,heloalconf , 

40 

d665,jai rsupreq, 

41 

f755,trkintel , 

42 

c460,comspot. 

43 

Figure  3.  Portion  of  msgindex  File 


message.  Classified  messages,  however,  should  be  grouped  together, 
preferably  at  the  end  of  the  fOe  so  they  can  easily  be  extracted  if 
an  unclassified  system  is  desire'*. 

2.1.2  Concatenate  Messages  (catmsg)  File 

The  concatenate  messages  file,  catmsg,  is  a  shell  program  which 
TM 

uses  the  UNIX  system  "cat"  command  to  concatenate  the  message  des¬ 
cription  files  into  one  large  file.  This  file  is  required  in  the 
building  of  a  data  base  (see  section  4). 

As  messages  are  added  to  or  removed  from  the  data  base,  it  is 
necessary  to  appropriately  update  the  shell  program  as  it  is  the 
contents  of  this  file  which  define  the  final  contents  of  the  data 
base.  Figure  4  shows  the  catmsg  shell  program  with  its  list  of 
short  message  names  (the  names  of  the  message  files).  Each  entry  in 
this  file  is  terminated  by  a  backslash  (\)  character. 

Due  to  the  number  of  arguments  that  the  "cat"  command  will 
take,  with  the  maximum  number  being  approximately  40,  catmsg  first 
concatenates  half  of  the  messages  with  the  result  written  to  msgl, 
concatenates  the  second  half  with  the  result  written  to  msg2,  and 
then  concatenates  msgl  and  msg2,  with  the  result  written  to  msgs, 
and  removes  msgl  and  msg2.  If  a  large  number  of  files  are  added  to 
the  existing  data  base,  more  concatenations  may  have  to  be  performed 
so  that  the  number  of  arguments  for  each  evocation  of  the  "cat" 
command  is  less  than  40.  We  are  left  with  a  single  file,  msgs,  of 
all  the  messages. 

TM 

:  UNIX  and  PWB/UNIX  are  trademarks  of  Bell  Telephone 

Laboratories,  Inc. 
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cat\ 
jsarreq\ 
aporalot\ 
crossdat\ 
reqstataskX 
tacopdat\ 
tecfriopdatX 
alord\ 
jlnctarepX 
airevent\ 
abchanqe\ 
acsamstatX 
engstsX 
jtnf lt\ 
msgchanqerepX 
sarsit\ 
sarir\ 
icasintreqX 
iairre<i\ 
al  r-»q\ 

>  :nsql 
cat\ 
ireereqX 
iescreqX 
isnpreqX 
inittvmVX 
reqconfX 
reehar*1\ 
a  i  r  lefccinX 
fl tcont info\ 
a  ir1efvern\ 
aknl'IqX 
alms ns o  A 
crossconfX 
trkrejA 
fltpln\ 
ies  iqareaX 
ecmlat\ 
errployalocX 
sortalotX 
trkmanX 
heloal<iat\ 
heloalconfX 
ja  LrsupreqX 
canspotX 
trkintelX 
>  ms ql 

cat  msql  'nsg?  >msqs 
rm  msql  'tisq? 


4.  Portion  of  catmsg  Fil 


2.1.3  Message  Description  Files 


The  JINTACCS  messages  supported  by  the  JAMPS  program  are  in 
files  which  contain  all  of  the  necessary  descriptive  and  processing 
information.  Each  of  the  43  files  of  message  information  for  the 
Air  Ops  messages  which  were  installed  for  the  Air  Force  PTU  Certi¬ 
fication  are  accessed  according  to  the  short  message  name  of  the 
message.  It  is  these  message  files  that  are  concatenated  by  catmsg 
to  a  single  file  (msgs)  (see  paragraph  2.3).  Each  message  file  con¬ 
sists  of  three  parts,  with  an  optional  fourth  part.  An  example  of  a 
message  description  file  is  shown  in  figure  5.  This  figure  shows 
the  four  basic  parts  of  the  file  to  be  described  in  the  following 
paragraphs. 


2. 1.3.1  Identification.  The  first  part  of  each  file  identi¬ 
fies  the  message  by  message  number  and  edition  number.  The  token 
".msg"  is  used  to  identify  the  message  number.  This  token  is  re¬ 
quired  in  every  message  file,  followed  by  a  blank  character,  and  the 
message  number.  In  figure  5,  the  file  aporalot  is  identified  by  its 
message  number,  A650.  Messages  will  be  retrieved  from  the  JAMPS 
data  base  by  their  message  number. 

Following  this  entry  is  the  edition  number.  Although  this  is 
not  presently  used  by  the  JAMPS  program,  it  must  be  entered  as  a 
zero  value  for  proper  operation.  A  future  version  of  the  JAMPS  pro¬ 
gram  may  allow  for  two  or  more  versions  of  the  same  message  type. 
This  will  be  permitted  by  the  use  of  the  edition  number. 

2. 1.3. 2  Keyword  Data  Set  Table.  This  part  of  the  message  des¬ 
cription  file  is  a  table  of  all  the  keyword  data  sets  which  comprise 
the  message.  The  KDS  presentation  number  is  a  sequential  number 
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.msq  a660 
.edition  Q 


field  order  is  as  follows: 

presentation  number  of  keyword  data  set 
keyword  data  set  name 
state  number 

mandatory  indicator  (m  or  M,  if  mandatory) 
repeatabi I ity  indicatorfr  or  R,  if  repeatable) 
version  number  (optional,  blank  will  use  most  recent  version) 
delete  indicator  (l=delete  on  input, 2=delete  on  output, 3=delete  on 
input  and  output,  blank  or  0=used  for  both  input  and  output) 


P,  KDS, 


1 ,  from, 

2,  to, 

1,  info, 

4,  class, 

6,  sic, 

6,  exer, 

7,  oper, 

i ,  msgid, 

4,  ref, 

ID,  canx, 

11,  Verio, 

If,  appor, 

li,  6alot, 

14,  tqtpri, 

lb,  aknldq, 

1 b  ,  rmk  s , 

I’,  dwnqrade. 


ST,  M,  R,  V,  t) 


1 ,  m, 

2,  m,  r 

3,  .  r 

4 ,  m, 

5,  . 

6,  , 

7,  , 

8,  m, 

9,  .  r 

ID,  . 

11 ,  m, 

12,  m,  r 

13,  , 

14,  .  r 
lb.  , 

16  ,  m, 
17,  , 


made  repeatihle  by  rev.  1,  TIDP 


•state 


D,  1 

1  ,  p 

2,  2,  3,  4 

3,  3,  4 

4,  6,  6,  7 ,  B 

6,  6,  7,  H 
h  ,  4 

7.8, 

8,  4,10,11 
9,4,10,1 1 
10,11 
11  ,12 

12.12,1  1,14,16,16 

13.14.16.16 

14.14.16.16 

16.16 


;from  mandatory 
:to  mandatory 
;to  is  also  repeatable 
; info  is  repeatable 
;class  mandatory 

;choose  either  exer  or  oper 

;msqid  is  mandatory 

;perid  mandatory 
;apor  is  mandatory 
,apor  is  repeatable 

:tqtpri  is  repeatable 


16,17,#  ;rmks  mandatory 

17.  *  -.dwnqrade  optional  as  result  of  PTR 

;  following  area  is  optional  and  used  for  mandatory  entries  in 
;  certain  fields  of  keyword  data  sets 

field  order  is  as  follows 

presentation  number  for  applicable  keyword  data  set 
relative  field  number  to  which  entry  applies 
entry  to  be  inserted  (will  be  used  as  a  character  strinq) 
protection  code  for  data  (p  protected,  u  or  blank  unprotected) 

.man 

4 .1  ,s  e  c  r  p  t ,u  ;c 1  ass 
H , I ,apora lot  ,p  ;msnid 

Figure  5.  Message  Description  File 
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assigned  to  each  different  KDS,  and  is  shown  in  the  first  column. 
This  number  is  the  KDS  appearance  order  in  the  MED.  Another  number, 
the  state  number,  is  assigned  to  each  KDS,  as  seen  in  the  third 
column.  In  most  cases,  the  presentation  number  is  identical  to  the 
state  number.  The  KDS  name  appears  in  the  second  column.  A  manda¬ 
tory  indicator  ( "m"  or  "M"  if  mandatory,  blank  otherwise),  is  in 
column  four  and  the  next  column  contains  a  repeatability  indicator 
("r"  or  "R"  if  repeatable,  blank  otherwise).  The  version  number 
(optional,  blank  will  use  the  most  recent  version)  is  in  column  six 
and  the  last  column  contains  the  delete  indicator.  The  delete 
indicator  is  presently  not  implemented;  it  is  reserved  for  future 
use. 


2. 1.3. 3  State  Tables.  The  third  section  of  the  message  des¬ 
cription  file  is  the  state  table,  which  shows  the  interdependencies 
and  interrelationships  of  the  keyword  data  sets.  This  table  is 
created  from  the  data  in  the  preceding  table,  mainly  the  mandatory 
and  repeatable  indicators,  and  the  information  found  in  the  TIDP, 
specifically  the  group  repeatability  indicators.  The  state  table  is 
used  solely  for  the  message  validation  process.  The  creation  of 
state  tables  is  explained  in  greater  detail  in  appendix  A. 

2.1.4  Prepopulation 

Prepopulation  data  is  data  added  to  a  message  by  the  JAMPS 
system  as  a  convenience  to  the  operator  when  the  field  entry  is 
invariant.  The  optional  fourth  part  of  the  message  description  file 
is  used  for  the  prepopulation  (i.e.,  initial  or  default  values)  of 
mandatory  entries  in  certain  KDS  fields.  The  format  of  this  part  of 
the  file  Is  the  presentation  number  of  the  KDS,  the  relative  field 
number  to  which  the  entry  applies,  the  entry  to  be  inserted  (used  as 


a  character  string),  and  a  protection  code  ("p"  if  write-protected, 
and  "u",  or  blank,  if  unprotected).  If  prepopulation  data  is  write' 
protected,  it  cannot  be  changed  by  a  JAMPS  terminal  operator. 

2.2  Keyword  Data  Set  Files 


From  the  messages  that  make  up  the  data  base,  a  unique  set  of 
KDS's  is  extracted.  This  data  and  an  index  of  the  data  comprise  the 
KDS  file.  Following  is  a  description  of  the  KDS  index  and  the  KOS 
file. 


2.2.1  Keyword  Data  Set  Index  (kdsindex)  File 

The  kdsindex  file,  a  portion  of  which  is  shown  in  figure  6,  is 
a  list  of  all  the  keyword  data  sets  used  in  the  messages.  Similar 
to  the  message  index  file,  the  KDS  index  must  have  the  ".kdsindex" 
token  as  the  initial  entry.  The  format  of  the  file  is  the  KDS  name 
followed  by  its  index  number  and  version  number.  A  blank  entered 
for  the  version  number  will  be  interpreted  by  the  system  as  a  zero. 
The  kdsindex  file  is  arranged  in  alphabetical  order,  with  the  excep¬ 
tion  of  the  JANAP  and  MSGCHANGEREP  keyword  data  sets.  The  JANAP 
keyword  data  sets  are  used  to  provide  the  information  for  framing 
the  JINTACCS  message  for  trasmitt.al  according  to  JANAP  128(H)  stan¬ 
dards.  This  order  was  used  for  ease  of  maintainability,  but  there 
are  no  system  requirements  that  this  must  be  observed.  Classified 
keyword  data  sets  should  be  appended  to  the  end  of  the  file  so  that 
they  can  be  easily  extracted  if  it  is  necessary  to  declassify  the 
file. 
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kdsindex 


;  field  order  is  as  follows: 


keyword  data  set  name 
keyword  data  set  number 

version  number  (  blank  is  interpreted  as  zero  (0)) 


FROM, 

1 

TO, 

2 

INFO, 

3 

AMPN , 

4 

NARR, 

5 

RMKS , 

6 

CLASS, 

7 

CHANGE, 

199 

CANCEL, 

8 

DELETE, 

9 

AFTER, 

10 

ADD, 

11 

6AL0T, 

13 

6APPDIS, 

14 

6BASIC , 

• 

15 

• 

AAR, 

58 

AAW , 

59 

ABORT, 

60 

ACEMER, 

61 

ACLOSS, 

62 

ACLOST, 

• 

63 

• 

TGTPRI , 

188 

TIMEAMP, 

189 

UNABLE, 

190 

UNITLOC, 

191 

ZZREF , 

192 

OTHERSAR, 

193 

COMEV , 

194 

INTELTK, 

195 

LOCN, 

196 

RELOC, 

197 

TKAMP , 

198 

Figure  6.  Portion  of  kdsindex  File 
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2.2.2  Keyword  Data  Set  (kdss)  File 

The  kdss  file  is  a  file  of  all  the  keyword  data  sets  and  their 
component  parts.  A  section  of  the  kdss  file  is  shown  in  figure  7. 
The  format  of  this  file  is  similar  to  the  message  description  files, 
however,  all  the  keyword  data  sets  are  in  one  file,  and  there  are 
only  three  parts  to  be  completed  for  each  keyword  data  set. 

2. 2. 2.1.  Identification.  The  first  part  of  the  kdss  file  is 
the  identification  and  contains  the  KDS  name,  the  KDS  type  (i.e., 
linear,  columnar,  free  text  or  JANAP),  and  the  version  number.  The 
KDS  type  identifier,  JANAP,  has  been  aded  to  the  JINTACCS-defined 
types  of  linear,  columnar  and  free  text  KDS's  to  aid  in  the  opera¬ 
tion  of  the  JAMPS  system.  A  JANAP-type  KDS  is  a  keyword  data  set 
which  contains  information  used  in  the  JANAP  framing.  If  the  KDS  is 
of  the  free  text  type,  the  identification  section  is  the  only  entry 
made  to  kdss. 

2. 2. 2. 2  Tables.  The  second  part  is  a  table  containing  the 
field  number,  the  DFI  number,  the  DU I  number,  the  state  number,  the 
print  position  for  the  field  header  (only  for  a  columnar-type  KDS), 
a  mandatory  indicator  ( "m"  or  "M"  If  mandatory),  a  repeatability 
indicator  ("r"  or  "R"  if  repeatable),  a  field  descriptor  indicator 
("1"  if  required,  "0",  or  blank,  if  not  required),  and  a  delete 
indicator.  The  delete  indicator  is  presently  unimplemented  but  Is 
reserved  for  future  use. 

2. 2. 2. 3  Keyword  Data  Set  State  Tables.  The  third  part  is  the 
state  table  which  defines  the  interdependencies  and  interrelation¬ 
ships  that  can  not  be  properly  conveyed  in  the  preceding  table.  The 
state  table  Is  used  solely  for  validation  purposes. 
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•  kos  from 

. JANAP 
.VERSION  0 


•  MELOS 

MHO  ORDER  IS  AS  FOLLOWS: 


FIELD  NUMBER 
OF  I  NUE*£R 
DUI  NUMBER 
STATE  number 

PRINT  POSITION  FOR  FIELD  HEADER  (ONLY  USED  FOR  TYPE  COLUMNAR) 
MANDATORY  INDICATOR  (M  OR  M.  IF  MANDATORY) 

REPEATABILITY  INDICATOR^  OR  R,  IF  REPEATABLE) 

FIELD  DESCRIPTOR  INDICATOR  (1-RE0UIRED,  0  OR  BLANK* NOT  USED) 

DELETE  INDICATOR  (1-DELETE  ON  INPUT  ,2-DELETE  ON  OUTPUT  ,3-DELETE  ON 
INPUT  AND  OUTPUT,  BLANK  OR  O-USEO  FOR  BOTH  INPUT  ANO  OUTPUT) 


P,  DM  .  IHJl .  St ,  PR 


R 


0 


1.  t!40<).  001.  1. 

2.  (1401.  001.  ?, 

3.  H40?,  00).  3, 

1,  f 1403,  001 .  4  . 
S,  E 1404,  001,  S, 
ft,  F 1 40S ,  001 ,  A. 
I .  Cl 40ft,  001,  7, 


.PLA 

; ROUTING  INDICATOR 
; ADDRESSEE  DESIGNATOR 
;ClASSIF ICAT ION 
; PRIMARY  PRECEDENCE 
SECONDARY  PRECEDENCE 
;DATE/TIN|  GROUP 


•S’ATt 


«■.  1.  2 

1,  2,  4 

2.  3 

3,  4 

4.  *»,  »>. 
b.  ft.  ■* 


NIST  HAVE  EITHER  PLA  OR  R1  AND  ADDR 
riASSIf 1CATI0N  IS  MANDATORY 
IF  Hi  THEN  MUST  INCLUDE  ADDR 


.DATE  TIME  GROUP  IS  MANDATOR? 


.*ns  &AiiU 

.COLUMNAR 
•VERSION  1 


.e  tuns 


1, 

E09H7.  Oil. 

1.  2.  M 

2 . 

E 098 7 ,  032. 

2,  1ft.  M 

3, 

E  0107 ,  004. 

3.  30.  M 

4  . 

f on u ,  0??. 

4.  IS ,  M 

S. 

IDSIJ,  101. 

S.  40. 

ft. 

FO907,  023. 

S.  47. 

7. 

EOS? 7.  001. 

7.  ftl. 

•SrAIE 


I. 

1.  >. 

?.  3. 

1.  4. 

«.  S,  6.  K  •. 
S.  ft.  T,  #. 

5: 

•KOS  AAR 
.LINEAR 
•VERSION  0 

•FIELDS 

1.  EOSOO.  024. 

2.  E0491.  002, 

3.  E06S1 ,  002, 

3,  E0681 ,  002. 

4,  E06SI .  003. 

4.  E0681 ,  003. 

5,  C0469,  008, 

5,  C049>,  OOS. 

S.  CO490.  002. 


•STATE 

0.  I. 

1.  2, 

2 ,  3.  4. 

3,  S.  6, 

4,  S.  ft, 

s.  b, 

6,  7.  8, 

7,  7,  8. 

0.  7,  8, 

9,  7,  8, 

•  KOS  RMKS 
. FREE  TEXT 
•VERSION  0 

Figure  7.  Portion  of  kdss  File 


I.  .  m.  . 

?.  .  m.  .  i 

3,  .  M,  . 

4,  .  M.  . 

5,  .  .  . 

ft,  .  .  . 

7,  ,  M,  R, 

8,  .  N,  », 

9,  .  M,  «, 
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Each  KDS  is  entered  in  the  kdss  file  in  a  relatively  alphabet¬ 
ical  order.  Again,  this  order  need  not  be  preserved  for  system 
operability,  but  may  be  desired  for  ease  of  maintenance.  Like  the 
kdsindex  file,  classified  keyword  data  sets  should  be  grouped  at  the 
end  of  the  file. 

2.3  Elemental  Files 

The  elemental  files  represent  the  lowest  level  of  the  JAMPS 
structure.  As  such,  these  files  not  only  form  part  of  the  struc¬ 
ture,  like  the  message  and  KDS  files,  but  also,  in  certain  in¬ 
stances,  define  the  contents.  Three  of  these  files  will  be 
described  at  the  elemental  level:  the  DFI/DUI  file,  the  Field 
Descriptor/Field  Header  file,  and  the  Codes  file. 

2.3.1  DFI/DUI  (dfidui )  File 

The  dfidui  file  is  a  unique  set  of  all  the  DFI/DUI ’ s  used  in 
suDport  of  the  JAMPS  system.  A  section  of  the  dfidui  file  is  shown 
in  figure  8.  Each  DFI/DUI  is  handled  according  to  its  DUI  indica¬ 
tor:  "com",  "dif",  or  "chn".  All  data  elements  which  are  chained; 
that  is,  if  the  DFI  is  a  "C"-tvpe  DFI,  use  the  DUI  Indicator  "chn" 
(chain).  All  other  DFI/DUI' s  fall  into  the  remaining  two  categories 
which  can  be  determined  by  examining  all  DUI's  which  appear  for  a 
given  DFI.  The  "com"  (common)  Indicator  is  used  If  all  DUI's  for  a 
given  DFI  have  the  same  minimum  and  maximum  code  lengths,  message 
map  characters  and  left  or  right  justification  flags  within  the 
field.  If  one  or  more  of  the  DUI's  differ  from  any  other  with  re- 
soect  to  any  of  these  characteristics,  the  "dif"  (different)  indi¬ 
cator  is  used  as  the  DUI  indicator.  Originally  a  fourth  type, 
"altchn"  (alternate  chain),  was  possible.  However,  JINTACCS  removed 
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com  eOOOl.l  ,v,l,6,x 


.dif  e0002 
.dul  001,1 ,v,l ,17,x 
.dui  007,1  ,v,l,17,x 
.dui  010,1  ,v,l,17,x 
.dui  015,1  ,v,l,17,x 

•  dui  018,1  ,v,l  ,17,x 
.dui  019,1  ,v, 1,17, x 
.dui  020,1  , v ,1 ,12,x 

•  dui  021,1 ,v, 1,12, x 
.dui  022,1 ,v,l,12,x 
.dui  023,1  , v,l, 17, x 
.dui  024, l,v, l,17,x 
.dui  025,1  ,v,l,17,x 
.dui  027,1  ,v,l  ,17 ,x 
.dui  028,1 ,v,l ,12,x 
.dui  031,1 ,v, 1,12, x 

.dif  e0003 
.dui  001,r,v,2,4,n 

•  dui  002,1  , v ,  1 ,6 ,x 

.dif  e0007 
.dui  001,l,f,,l,a 

.com  e0008,l ,f ,  ,6,aannnn 

•com  e0009,l ,f,,9,x 

.chn  cOOll.l ,f , ,15,nnnnnnannnnnnna 

•  chain 

e0017,001 
e0156 ,002 
e0157 ,002 
e0158,002 
e0018 ,001 
e0156,003 
e0157,003 
e0158,003 


Figure  8.  Portion  of  dfidui  File 
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all  but  one  of  the  alternate  chain-type  DFI's.  For  ease  of  opera¬ 
tion,  the  remaining  alternate  chain  was  replaced  in  the  data  base  by 
two  chains.  This  replacement  does  not  change  the  operation  of  the 
program,  and  it  is  transparent  to  the  operators. 

The  format  of  the  entry  for  a  "com"- type  DUI  is  the  DUI  indica¬ 
tor,  followed  by  the  DFI  number,  a  left/right  justification  flag 
("1“  for  left,  and  "r"  for  right),  a  field  length  indicator  (”v"  for 
variable  length,  and  "f"  for  fixed  length),  the  minimum  field 
length,  the  maximum  field  length,  and  the  message  map  characters. 

If  only  one  message  map  character  appears,  all  characters  in  the 
field  are  of  that  type. 

When  a  DUI  is  a  "dif"  type,  the  entry  is  the  DUI  indicator  fol¬ 
lowed  by  the  DFI  number.  This,  in  turn,  is  followed  by  each  DUI 
number  and  its  left/right  justification  flag,  field  length  indica¬ 
tor,  minimum  field  length,  maximum  field  length,  and  message  map 
characters. 

The  format,  for  the  entry  of  a  "chn"-type  DFI  is  the  DUI  indi¬ 
cator,  followed  by  the  DFI  number,  left/right  justification  flag, 
field  length  Indicator,  minimum  field  length,  maximum  field  length, 
and  message  map  characters.  This,  In  turn,  is  followed  by  the  ele¬ 
mental  components  of  the  chain;  the  DFI  number  and  the  DUI  number. 

2.3.2  Field  Descriptor/Field  Header  (fdfh)  File 

The  fdfh  file  is  a  list  of  all  DFI /DUI * s  and  their  respective 
field  descriptors  and  field  headers.  The  format  of  the  file  is  the 
DFI  number,  followed  by  the  DUI  number,  the  field  descriptor  and 
field  header.  Figure  9  shows  sections  of  the  fdfh  file. 
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fdfh 


eOOOl,  001 .msnno.msnno 
e0002,  0Q1-, cal  lsign , cal  1  sign 
e0002,  007,authcs,authcs 
e0002,  010,intunt,intunt 
e0002,  015,cntcs 
e0002,  018, from, from 
e0002,  019, to, to 
e0002,  020,acsign,acsign 
e0002,  021  .tankercs  .tankercs 
e0002,  022,reccs,reccs 
e0002,  023,initcon,initcon 
e0002,  024,fnl con, fn Icon 
e0002,  025,dclauth,dclauth 
e0002,  027 .rncorcs .mcorcs 
e0002,  028,rendcs,rendcs 
e0002,  031 ,atkaccs,atkaccs 
e0003,  002, regno, regno 


• 

e0987,  031, lose, lose 
e0987,  032, gain, gain 
e0987,  037,btlgrp,btlgrp 

e0992 ,  OOl.frgpri  .frgpri  -.missing  from  med 

el028,  001 .typalt ,typalt 

el029,  OOl.hzd.hzd 

el030,  001 ,ldtyp,ldtyp 

el031 ,  OOl.ldref 

el031,  002,onloc,onloc 

el031,  003,offloc,offloc 

el032,  001,geofil 

el040,  001 ,sidenr,sidenr 

el042,  001,spec-not  ;no  field  descriptor  in  MED 

el400,  001, pla  ;janap  128  dfis 

el401,  001, ri 

el402,  OOl.addr 

el403,  001, class 

el404,  OOl.priprec 

el405,  001, seep rec 

cl406,  001,dtg 


Figure  9.  Portion  of  fdfh  File 
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2.3.3  Codes  (codes)  File 


The  codes  file  contains  all  valid  code  entries  for  all  DFI/ 
Dill's.  This  file  is  used  for  validation  of  operator  entries  and  for 
the  display  of  minimum  and  maximum  code  lengths.  The  codes  file,  as 
well  as  the  itemcodes  file  (paragraph  2.4.2),  was  extracted  from  a 
System  Development  Corporation  (SDC)  print  tape  of  the  JINTACCS 
field  coding  report. 

Due  to  the  size  of  the  codes  file  and  to  aid  in  its  mainten¬ 
ance,  codes  has  been  divided  into  four  sections,  codesl,  codes2, 
codes3  and  codes4,  according  to  the  DFI/DUI  number.  Before  pro¬ 
cessing  the  source  files,  the  four  sections  are  concatenated  and 
written  to  codes.  For  the  remainder  of  this  manual,  the  four  sec¬ 
tions  will  not  be  referred  to  separately,  but  as  a  single  entity, 
codes.  A  portion  of  the  codes  file  is  shown  in  figure  10. 

The  first  entry  to  the  codes  file  is  the  DFI  type,  i.e.,  "E"  or 
"C" ,  followed  by  the  DFI  number  and  DUI  number,  with  no  separating 
space  between  the  two,  and  the  DUI  name.  This  is  followed  by  the 
data  items  in  a  column  on  the  left,  and  the  data  item  codes  in  a 
corresponding  column  on  the  riqht.  The  data  items  and  data  item 
codes  appear  in  the  codes  file  in  the  same  form  as  they  appear  In 
the  HED,  i.e.,  if  a  code  or  data  item  spans  more  than  one  line,  it 
will  span  more  than  ore  line  in  the  codes  file.  The  codes  file 
makes  use  of  manually  entered  concatenation  symbols  to  properly 
concatenate,  upon  processing,  the  codes  which  span  more  than  one 
line.  The  concatenation  symbols  used  are  the  sharp  sign,  "#",  to 
Indicate  a  blank  should  be  left  between  the  two  sections  of  the 
code,  and  an  equal  sign,  to  Indicate  a  hyphen  which  should  be 

deleted  upon  concatenation.  The  data  items  and  codes  are  then 


E  001  DO]  MISSION  NUMBER 

(LITERAL) 

(SEE  INSTRUCTIONS) 
002001  CALL  SIGN 

LITERAL) 

(SEE  INSTRUCTIONS) 
NONE 
UNKNOWN 


(LITERAL) 


*  (LITERAL) 

* 

*  NONE 

*  UNK 

CLEARANCE  AUTHORITY  CALL  SIGN 
(LITERAL)  *  (LITERAL) 

(SEE  INSTRUCTIONS)  * 

NONE  •  NONE 

UNKNOWN  *  UNK 


00200? 


F  515001 


POINT  TYPE 


HAZARD, 

IMPACT  POINT 

IMPACT  POINT 

HAZARO. 

GROUND  ZERO 

GROUNO  ZERO 

HAZARD, 

AIR/WEAPON  ENTRY 

AIR  WEAPON! 

POINT 

ENTRY  POINT 

hazard. 

MISSILE  LAUNCH 

LAUNCH  POINT 

POINT 

HAZARD , 

ECM  DECOY 

ECM  DECOY 

GENERAL 

REFERENCE  POINT 

GENERAL  REF< 

ERENCE  POINT 

MARSHAL 

POINT 

MARSHAL! 

POINT 

WAY  POINT 

WAY  POINT 

CORRIDOR  TAB 

CORRIDOR  TAB 

PIM 

PIM 

JISPOSI  TftlN  CENTER 

DISPOSITION! 

CENTER 

F  S 1400 l  MINUTE  northing,  georef 

*  (00  *  (00 

*  THRU  ♦  THRU 

*  59)  •  59) 


E  627001 

♦  (00 

*  THRU 

*  77/7) 


COOE  ( 1FF/SIF) 


(00 
THRU 
7  7  7  7  ) 
(OCTAL) 


E  674001 
A 

B 
C 
0 
E 
F 


BEACON  COOE 


El 405001 

JANAP  SECONDARY  PRECEDENCE 

*  FLASH 

•  Z 

♦  IMMEDIATE  *  0 

•  PRIORITY 

•  P 

•  ROUTINE 

*  R 

C 1406001 

JANAP  DATE/TIME  GROUP 

E1407001 

JANAP  DAY  OF  MONTH 

E 1408001 

JANAP  BLANK 

Figure  10. 

Portion  of  codes  File 
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delimited  by  asterisks.  After  processing  the  SDC  tape,  the  aster¬ 
isks  appeared  in  columns  1,  32,  and  48.  The  asterisks  are  not 
required  to  appear  in  these  columns,  but  are  used  merely  as  a 
convenient  delimiter  in  processing  the  file. 

The  DFI/DUI's  appear  one  right  after  the  other  with  no  separa¬ 
tion.  The  codes  file  appears  in  DF I  order  although,  once  again, 
this  is  not  required  for  system  operation. 

2.4  Help  Text 


There  are  two  files  which  provide  the  data  used  in  conjunction 
with  the  "HELP"  capability  of  the  JAMPS  program.  A  file  named  help- 
text  contains  the  defining  textual  information,  while  the  ftemcodes 
file  provides  the  discrete  data  items  and  data  item  codes.  Like  the 
codes  file,  the  helptext  and  itemcodes  files  are  stored  in  four 
sections  according  to  DF I /DU I  number,  which  are  concatenated  before 
processing  of  the  source  files.  For  the  remainder  of  the  manual, 
however,  they  will  be  referred  to  as  single  files,  helptext  and 
itemcodes. 

The  helptext  file  was  the  result  of  a  combined  Air  Force  and 
MITRE  effort.  Help  text  coding  sheets  were  completed  by  Air  Force 
personnel  and  entered  into  the  system  by  System  Architecture  In¬ 
corporated  (SAI)  contractors.  This  method  provided  approximately 
one— third  of  the  helptext  file.  The  remaining  portion  of  the  file 
was  extracted  from  the  SDC  print  tape  and  manually  edited  into 
usable  form. 
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2.4.1  Help  Text  (helptext)  File 


Figure  11  shows  sections  of  the  helptext  file.  The  first  entry 
to  the  helptext  file  is  the  token  ".DFI".  This  is  followed  by  the 
0F1  type  ("E"  or  "C"),  then  the  DFI  and  DUI  numbers,  with  this  in¬ 
formation  appearing  exactly  as  it  appeared  in  the  codes  file,  fol¬ 
lowed  by  the  DUI  name. 

The  next  section  of  the  file  is  the  DF I /DUI  definition,  and  in¬ 
formation  on  how  to  enter  data  into  the  given  field.  The  definition 
is  preceded  by  "DEFINITION:",  immediately  followed  by  the  actual 
information  on  the  same  line.  The  entry  format  of  the  definition 
should  be  in  a  readable  form  since  it  will  be  displayed  exactly  as 
entered.  The  "DEFINITION:"  token  is  mandatory;  likewise,  a  line  of 
defining  text  cannot  exceed  79  characters,  the  maximum  width  of  the 
display  screen.  If  the  help  text  information  spans  more  than  18 
lines,  the  ".PAGE"  token  must  be  used  to  show  the  page  separation. 

The  final  entry  to  the  file  must  be  the  ".DFI"  token  in  order 
for  all  DFI's  to  be  processed  correctly. 

t 

2.4.2  Data  Items  and  Data  Item  Codes  (itemcodes)  File 

The  itemcodes  file,  portions  of  which  are  shown  in  figure  12, 
is  used  in  conjunction  with  the  helptext  file  for  display  of  field 
definition  and  entry  data  in  HELP  or  CONVERSATION  mode. 

The  format  of  the  itemcodes  file  is  identical  to  the  codes 
file.  The  DFI  type,  DFI  number,  DUI  number,  and  DUI  name  are  fol¬ 
lowed  by  the  data  items  and  data  item  codes,  delimited  by  asterisks. 
Like  the  codes  file,  the  positioning  of  the  asterisks  and  the  width 


•  OF  I 

E  l  .'1001 
MISSION  NUMBER 

DEFINITION:  THE  IDENTIFYING  NUMBER  ASSIGNED  TO  A  MISSION. 

ENTER  THE  MISSION  NUMBER.  THIS  NUMBER  CANNOT  BE  LONGER  THAN  6  ALPHANUMERIC 
CHARACTERS. 


.DI  I 

i  ooinoL’ 

COLLECTOR  MISSION  NUMBER 

H  l-  IN!  1 1  ON;  THE  IDENTIFYING  NtIMRER  ASSIGNED  TO  A  COLLECTIVE  MISSION. 

■V'R  HI  MISSION  NUMBER.  THIS  NUMBER  CANNOT  BE  LONGER  THAN  6  ALPHANUMERIC 
i  MAR  AC  IFRS. 


i;  hid/ 

)N  :  OCAMON,  LAT./LONG 

;*  IV r ION:  THE  LOCATION  AT  WHICH  AN  AIR  MISSION  IS  TO  BE  PERFORMED.  THESE 
;  WORD ! NATES  CAN  BF  A  TARGET,  ORBIT,  COMBAT  AIR  PATROL  POINT,  STATION, 


si  1  NEXT  ->AGl  FOR  I NSIRUCT  IONS  ON  HOW  TO  ENTER  DATA  FOR  THIS  FIELD. 

.  PAGE 

HIS  Is  AN  EXAMPLF  OF  A  COMPLETE  LOCATION  ENTRY: 

55 3D30N1 303030E 

•N'-R  THE  FOLLOWING  SERIES  OF  CHARACTERS  AND  NUMBERS: 

1.  THE  LATITUDINAL  DEGREES  (00-90) 

/.  HE  I  AT  I TUD INAL  MINUTES  (00-59) 

3.  rUI  LATITUDINAL  SECONDS  (00-59) 

1.  TUI  LATITUDINAL  HEMISPHERE 
N  NORTH  HEMISPHERE 
S  SOUTH  HEMISPHERE 

5.  THE  LONGITUDINAL  DEGREES  (OOO-IBO) 

B .  HI  I  DNf.ITUDINAL  MINUTES  (00-59) 

1.  HI  1 ONGI TOO  I NAL  SECONDS  (00-59) 

H.  'HI  LONGITUDINAL  HEMISPHERE 
F  FAS'  HfMIsi’HERF 
w  w  si  him;  where 


Figure  11.  Portion  of  helptext  File 
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(LITERAL) 


E  001001  MISSION  NUMBER 

*  (LITERAL)  *  (LITERAL) 

*  (SEE  INSTRUCTIONS)  * 

E  002001  CALL  SIGN 

*  (LITERAL)  *  (LITERAL) 

*  (SEE  INSTRUCTIONS)  * 

*  '.jNF  *  NONE 

*  UNKNOWN  *  UNK 

E  002007  CLEARANCE  AUTHORITY  CALL  SIGN 

*  (LITERAL)  *  (LITERAL) 

*  (SEE  INSTRUCTIONS)  * 

*  NONE  *  NONE 

*  UNKNOWN  *  UNK 


POINT  TYPE 


HAZARD,  IMPACT  POINT 
HAZARD ,  GROUND  ZERO 
HAZARD,  AIR/WEAPON  ENTRY 
POINT 

HAZARD,  MISSILE  LAUNCH 
POINT 

HAZARD,  ECM  OECOY 
GENERAL  REFERENCE  POINT 

MARSHAL  POINT 

WAY  POINT 
CORRIDOR  TAB 
PIM 

DISPOSITION  CENTER 


*  IMPACT  POINT 

*  GROUND  ZERO 
•AIR  WEAPON 

*  ENTRY  POINT 

*  LAUNCH  POINT 

* 

*  ECM  DECOY 

‘  GENERAL  REF- 

*  ERENCE  POINT 

*  MARSHAL 

*  POINT 

*  WAY  POINT 

*  CORRIDOR  TAB 

*  PIM 

*  DISPOSITION 

*  CENTER 


'4001  MINUTE  NORTHING,  GEOREF 

(00  ♦  (00 

THRO  •  THRU 

5)  •  69) 


E  627001 

*  (00 

•  THRU 

*  Till) 


CODE  ( IFF/SI F ) 


E  6M001  BEACON  CODE 

•  A  THRU  F 


A  THRU  F 


E140S001  JANAP  SECONDARY  PRECEDENCE 

*  FLASH  *  Z  * 

*  IMMEDIATE  *  0  * 

*  PRIORITY  *  P  * 

*  ROUTINE  *  R  * 

Cl 406001  JANAP  DATE/TIME  GROUP 

E 1407001  JANAP  DAY  OF  MONTH 

E 1408001  JANAP  BLANK 

Figure  12.  Portion  of  itemcodes  File 


of  the  columns  are  flexible.  Entries  to  itemcodes  will  be  displayed 
in  the  HELP  mode  as  they  appear  in  the  source  file.  For  this  reason 
it  may  be  desirable  to  concatenate  codes  that  span  more  than  one 
line  in  itemcodes  rather  than  having  them  displayed  in  sections. 

This  may  be  done,  however  the  total  line  length  cannot  exceed  79 
characters,  the  width  of  the  display  screen. 

2.5  JANAP 

The  JANAP  data  consists  of  three  files  which  provide  the  means 
to  prepopulate  certain  fields  of  a  new  message.  This  information  is 
used  as  the  contents  of  the  TO  and  FROM  KDS's  and  consists  mainly  of 
address  information.  The  JANAP  files  are  the  Adr  file  which  con¬ 
tains  addresses,  the  Orig  file  containing  data  pertaining  to  the 
message  originator,  and  the  Rout  file,  the  list  of  addressees  for 
each  message. 

2.5.1  Address  (Adr)  File 

The  first  of  these  files  is  Adr,  or  the  address  file.  This 
file  is  accessed  by  the  Plain  Language  Address  (PLA),  which  is  part 
of  each  entry.  A  complete  entry  consists  of  three  pieces  of  infor¬ 
mation:  a  PLA,  a  routing  indicator,  and  an  ordinary  address.  The 
PLA,  which  is  also  the  keyword  of  the  file,  is  a  14-character,  or 
less,  alphanumeric  abbreviation  of  the  address.  The  PLA  is  used  by 
operators  to  specify  an  addressee  for  a  message.  The  routing  indi¬ 
cator  is  a  7-character,  or  less,  alphabetic  entry.  The  routing 
indicator  is  used  by  the  AUTODIN  Line  Controller  as  an  address  for 
the  switching  (or  routing)  of  messages  through  the  network.  The 
ordinary  address  can  be  up  to  57  alphanumeric  characters,  and  is  the 
real-world  address  of  an  Operational  Facility  (opfac). 
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2.5.2  Message  Originator  (Prig)  File 


The  Orig  file  consists  of  an  entry  for  each  operational  fa¬ 
cility  supported  by  the  JAMPS  system.  Each  entry  in  this  file  is 
identified  and  retrieved  by  a  four-  or  five-character  name,  which  is 
also  the  login  identity  for  that  opfac.  The  remainder  of  the  data 
in  the  entry  satisfies  the  FROM  fields  of  the  KDS.  In  addition  to 
this  data,  a  file  entry  has  the  transmission  channel  number  and 
name,  and  a  designator.  This  information,  although  not  part  of 
JINTACCS,  is  required  for  local  software  use  and  is  obtained  from 
the  Test  Coordinator.  The  information  from  this  file  is  used  to 
prepopulate  the  FROM  KDS  of  every  message  composed,  using  the  login 
identity  as  the  keyword  for  the  retrieval. 

2.5.3  Message  Routing  (Rout)  File 

The  third  file.  Rout,  is  used  to  prepopulate  messages  with  the 
TO  and  INFO  addressees.  This  information  is  configured  as  separate 
files  for  each  opfac  supported  by  the  JAMPS  system.  A  file  for  a 
specific  opfac  will  contain  an  entry  for  each  message  type  that  can 
be  originated  at  that  opfac.  For  each  message  type,  the  data  will 
consist  of  a  classification  code,  a  primary  and  secondary  prece¬ 
dence,  a  list  of  both  TO  and  INFO  PLA's. 

When  a  message  Is  to  be  composed,  the  JAMPS  program  will  use 
the  login  identity  and  the  message  type  entered  as  the  "compose" 
argument  to  find  the  prepopulation  data  in  the  file.  This  Informa¬ 
tion  will  then  be  copied  Into  the  message  format  and  displayed  to 
the  operator. 
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SECTION  3 


REVISING  THE  DATA  BASE 


3.1  Message  Revision 

The  message  data  base  files  are  designed  in  a  hierarchical 
order,  with  the  lower  levels  being  the  component  parts  of  the  upper 
levels.  The  hierarchical  order  of  the  JAMPS  data  base  is  shown  in 
figure  13. 

A  change  to  any  of  the  upper  levels  may  have  a  cascading  effect 
on  the  lower  levels.  For  example,  a  change  to  add  or  delete  a  mes¬ 
sage  may  involve  changing  as  few  as  three  files  or  as  many  as  ten. 

3.1.1  Addition/Deletion  of  a  Message 

In  order  to  add  or  delete  a  message  from  the  JAMPS  data  base, 
changes  must  be  made  to  the  msgindex  and  catmsg  files.  The  short 
message  name  must  be  entered  into  or  deleted  from  catmsg.  Each 
entry  in  this  file  most  be  followed  by  a  backslash.  The  msgindex 
file  is  updated  by  adding  the  message  number,  followed  by  the  short 
message  name,  and  ended  with  the  next  sequential  index  number.  The 
message  number  and  short  message  name  can  be  obtained  from  the  TIDP. 
Information  sources  will  be  discussed  in  further  detail  in  section 
6.  When  a  message  is  deleted.  It  is  advisable  to  renumber  the  mes¬ 
sage  index  numbers  In  msgindex.  Although  the  program  will  work 
properly  if  there  is  a  break  in  these  numbers,  the  cross  check  pro¬ 
gram  (see  paragraph  5.2),  will  cease  operating  when  It  encounters  a 
break;  all  messages  will  not  be  cross  checked. 
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Figure  13.  Hierarchical  Structure  of  JAMPS  Source  Files 
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The  deletion  of  a  message  is  completed  by  removing  the  separate 
message  description  file  for  that  message.  Any  keyword  data  sets  or 
fields  that  were  used  solely  by  the  deleted  message  may  be  removed, 
however,  it  is  not  necessary  to  do  so.  It  may  be  desirable  to  re¬ 
tain  the  message  file  and  the  related  keyword  data  sets  and  fields. 
This  would  eliminate  unnecessary  reentry  at  a  later  date  should  the 
message  be  reestablished  or  a  message  added  which  would  use  those 
fields  and  sets. 

( 

t 

To  add  a  message  to  the  data  base,  it  is  necessary  to  create  a 
message  description  file  for  the  message.  A  new  file  can  be  created 
by  issuing  the  UNIX  system  "edit"  command,  followed  by  the  short 
message  name.  Upon  issuance  of  the  "edit"  command,  the  system  will 
attempt  to  edit  an  existing  file  of  that  name  should  one  exist,  or 
will  create  an  empty  file  and  assign  the  given  name  to  that  file. 

i 

The  first  entry  to  the  file  is  the  message  number,  a  lower  case 
alphabetic  character  followed  by  three  digits.  This  is  preceded  by 
the  token  ".msg".  The  next  line  should  contain  the  edition  number 
preceded  by  the  token  ".edition".  It  is  necessary  that  the  tokens 
be  included  in  the  file,  as  the  processing  routine  will  search  for 
them  and  process  accordingly.  Comments  may  be  added  to  this  file  at 
any  place  when  preceded  by  a  semicolon.  The  comment  field  begins  at 
the  semicolon  and  continues  to  the  end  of  the  line.  The  next  entry 
should  be  a  table  in  the  format  discussed  in  paragraph  2.1.3.  The 
information  must  be  separated  by  commas.  The  spacing  of  the  columns 
Is  totally  arbitrary,  however,  an  easily  readable  format  should  be 
used. 


The  next  entry  is  the  state  table.  The  state  table  entry  must 
be  preceded  by  the  token  ".state".  This  table  should  be  built  using 
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the  information  provided  in  the  previous  table,  combined  with  the 
information  provided  in  the  TIDP.  If  any  fields  are  to  be  prepopu¬ 
lated,  the  state  table  should  be  followed  by  the  token  “.man",  and 
the  table  of  fields  to  be  populated  along  with  their  field  entries. 

When  all  entries  have  been  made  to  the  message  description 
file,  the  kdsindex  must  be  checked  to  ensure  that  the  data  base 
contains  all  keyword  data  sets  comprising  the  new  message.  If  any 
are  missing,  an  appropriate  entry  must  be  made  to  kdsindex  and 
subsequently  to  kdss. 

3.1.2  Change  Keyword  Data  Set  Indicator 

Revisions  to  the  TIDP  will  occasionally  remove  or  impose  man¬ 
datory  or  repeatability  standards  to  keyword  data  sets  that  pre¬ 
viously  were  not  defined  in  that  manner.  To  make  a  change  to  the 
KDS  indicators  for  a  given  message,  the  operator  must  edit  that 
message's  description  file.  The  appropriate  flag  should  be  added  to 
or  deleted  from  the  corresponding  data  set.  The  revision  of  KDS 
indicators  will  effect  part  or  all  of  the  state  table.  It  will  be 
necessary  to  evaluate  the  impact  of  the  change  and  revise  the  state 
table  accordingly. 

3.1.3  Addition/Deletion  of  Keyword  Data  Sets 

The  addition  of  a  new  message  to  the  data  base  will  usually  en¬ 
tail  adding  keyword  data  sets.  Keyword  data  sets  may  also  be  added 
or  deleted  from  existing  messages  through  JINTACCS  revisions.  In 
order  to  add  or  delete  a  KDS,  kdsindex  must  first  be  consulted  to 
see  If  the  keyword  data  set  exists  in  the  data  base.  If  a  KDS  Is  to 
be  added  to  kdsindex,  it  Is  advisable  to  retain  the  alphabetic 


35 


order,  unless  the  KDS  Is  classified.  The  index  number  assigned  to 
the  K0S  should  be  the  next  sequential  number  in  the  list.  No  re¬ 
numbering  of  the  KDS  numbers  is  required  when  adding  or  deleting  a 
keyword  data  set. 

The  addition  or  deletion  of  the  keyword  data  sets  must  be  made 
to  the  kdss  file.  The  deletion  of  a  KDS  involves  the  removal  of  the 
corresponding  entry  from  kdss.  When  adding  a  KDS  to  the  fields,  the 
alphabetic  order  should  be  preserved,  unless  the  KDS  is  classified. 
The  KDS  name  entry  is  preceded  by  ".KDS".  This  is  followed  by  the 
KDS  type  entered  as  ".LINEAR",  ".COLUMNAR",  ".FREETEXT"  or  ".JANAP”, 
followed  by  ".VERSION"  and  the  version  number.  This  information  may 
be  entered  as  lowercase  characters  and  converted  to  uppercase  char¬ 
acters,  using  a  lower- to- upper  processing  routine.  An  uppercase 
conversion  must  take  place  before  processing  of  the  JAMPS  data 
tables  if  kdss  was  entered  in  lowercase  characters.  The  table  of 
fields  and  state  table  are  completed  in  a  manner  similar  to  the 
message  table  of  keyword  data  sets  and  state  table. 

The  table  of  fields  should  be  preceded  by  ".FIELDS"  and  the 
state  table  preceded  by  ".STATE".  Note  that  a  number  of  fields  may 
have  the  same  presentation  number  In  the  kdss  file.  If  the  presen¬ 
tation  number  is  repeated,  it  indicates  that  the  field  is  an  alter¬ 
nate  contents  field  and  that  all  DFI/DUI's  listed  for  that  field  are 
valid  choices. 

A  change  to  the  kdslndex  file,  and  subsequently  to  the  kdss 
file,  may  require  changes  to  dfidul.  The  dfldul  file  should  be 
checked  to  ensure  that  all  the  fields  entered  in  kdss  do  exist  in 
the  data  base. 
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3.1.4  Change  Field  Indicator 


A  change  In  a  field's  mandatory  or  repeatability  definition 
changes  the  field  state  table.  After  changing  the  field  indicator 
entry  in  the  table  of  fields,  make  sure  that  the  state  table  cor¬ 
rectly  reflects  this  change. 

3.1.5  Field  Changes 

If  a  field  is  to  be  added  to  the  data  base,  at  least  one  entry 
must  be  made  to  dfldul.  Multiple  entries  may  have  to  be  made  to 
dfidui  if  a  chain- type  DFI  is  being  added  and  not  all  the  elemental 
DFI's  comprising  the  chain-type  DFI  are  in  the  data  base.  Entries 
must  be  made  to  the  Itemcodes  and  helptext  files.  These  entries 
will  be  discussed  in  paragraphs  3.2.1  and  3.2.2,  respectively.  An 
entry  must  be  made  to  fdfh  if  the  field  can  appear  by  itself  (i.e., 
not  as  part  of  a  chain),  and  an  entry  must  be  made  to  codes. 

In  adding  a  DFI/DUI  to  dfidui,  the  format  of  the  entry  is  as 
specified  in  paragraph  2.3.1.  The  addition  of  a  DFI/DUI  may  change 
the  DUI  indicator  from  "com"  (common)  to  "dif"  (different)  if  the 
new  entry  introduces  new  field  lengths,  left/right  justification,  or 
message  map  characters  differing  from  ones  existing  in  dfidui.  In 
this  case,  all  DUI's  must  be  made  into  separate  entries,  as  speci¬ 
fied  by  the  "dif"  format. 

In  adding  a  DFI/DUI  to  fdfh,  the  format  is  that  specified  in 
paragraph  2.3.2.  In  order  for  the  JAMPS  system  to  perform  correct¬ 
ly,  a  field  descriptor  must  be  entered  for  each  DFI/DUI.  A  field 
header  need  only  be  entered  if  the  DFI/DUI  is  part  of  a  columnar 
KOS.  If  a  field  descriptor  is  not  provided  in  the  MED,  the  field 


header  may  be  entered  as  both  the  field  descriptor  and  field  header. 
If  neither  is  provided,  an  appropriate  abbreviation  of  the  DUI  name 
or  usage  should  be  entered  for  the  field  descriptor  and,  if  requir¬ 
ed,  the  field  header. 

If  a  field  is  being  added  to  the  data  base,  an  entry  must  be 
made  to  codes.  The  format  discussed  in  paragraph  2.3.3  should  be 
followed  in  making  the  addition.  Any  codes  which  span  more  than  one 
line  should  be  examined  to  determine  if  a  concatenation  symbol  is 
necessary. 

Changes  to  data  fields  may  be  made  through  fdfh,  dfidui  or 
codes,  depending  on  what  is  being  changed.  A  change  to  the  message 
map  characters,  field  length,  or  left/right  justification  is  made 
through  the  dfidui  file,  whereas  a  change  to  the  field  header  or 
field  descriptor  is  made  to  fdfh.  A  change  to  the  valid  code 
entries  for  a  field  is  made  to  codes. 

3.2  Help  Text  Revision 

Sections  of  the  help  text  may  have  to  be  revised  in  order  to 
clarify  definitions.  Improve  readability,  or  update  the  available 
Information.  There  are  two  files,  helptext  and  Itemcodes,  which, 
when  combined,  provide  the  help  text.  Revisions  to  the  DFI/DUI 
definitions  would  be  made  in  the  helptext  file,  whereas  changes  to 
specific  valid  codes  would  be  made  In  the  Itemcodes  file. 

3.2.1  Code  Changes 

The  codes  that  are  displayed  as  part  of  the  help  text  are  In 
the  source  file,  itemcodes.  The  Itemcodes  file  is  in  the  same 
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format  as  the  codes  file  and  may  be  revised  in  the  same  manner  as 
discussed  in  paragraph  3.1.5.  Initially,  codes  which  spanned  more 
than  one  line  in  the  MED  also  span  more  than  one  line  in  the  codes 
and  Itemcodes  files.  However,  since  the  entry  in  the  itemcodes  file 
is  what  is  displayed  to  the  operators  in  the  HELP  and  CONVERSATION 
modes,  it  may  be  desirable  to  display  the  code  in  a  more  legible 
form.  The  code  may  be  changed  in  the  source  form  so  that  it  appears 
all  on  one  line.  Likewise,  this  will  be  the  displayed  format  of  the 
code  in  the  HELP  mode.  The  only  requirement  is  that  a  line  in 
Itemcodes  is  no  greater  than  79  characters,  including  the  delimiting 
asterisks. 


3.2.2  DFI  Definition  Revision 


Some  of  the  phrases  expressing  the  essential  nature  of  the 
meaning  of  the  DFI/OUI's  that,  are  published  in  the  MED  are  verbose 
and  provide  superfluous  Information  of  a  technical  nature.  Other 
definitions  are  brief  and  to  the  point.  The  definitions  of  the 
DFI/DUI's  which  appear  in  the  HELP  and  CONVERSATION  modes  are  In  the 
source  file  helptext.  Initially  these  were  gathered  from  the  MED 
definitions.  It  may  be  necessary  to  revise  some  of  the  helptext 
definitions  so  as  to  make  them  informative  and  concise.  The  format 
described  in  paragraph  2.4.1  should  be  followed  when  revising  the 
helptext  file. 

3.3  JANAP  File  Update 

The  three  JANAP  files  containing  prepopulation  data  as  de¬ 
scribed  In  section  2  can  be  revised  by  programs  specifically  written 
for  that  purpose.  These  programs,  which  ensure  proper  formatting 
and  provide  for  data  entry  validation,  are  the  subject  of  the  fol¬ 
lowing  paragraphs. 
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3.3.1  Address  (Adr)  File 


This  file,  which  is  basic  to  the  other  two  JANAP  data  files, 
can  only  be  altered  by  the  program  jbldadr.  When  this  program  is 
called,  it  will  first  read  the  entire  file  from  the  disk  into  mem¬ 
ory.  A  menu  is  then  displayed  on  the  CRT  which  allows  the  operator 
to  review  the  entire  file,  make  additions  or  deletions,  or  modify 
existing  entries. 

The  routing  indicators  are  seven  alphabetic  characters  or  less, 
and  the  ordinary  address  can  be  as  long  as  56  alphanumeric  charac¬ 
ters.  Both  of  these  items  are  checked  before  being  entered  into  the 
file.  Any  errors  will  cause  the  display  of  an  appropriate  message 
and  allow  for  reentry  of  data. 

As  changes  are  being  made  to  the  file,  all  entered  data  is 
checked  for  validity  to  the  extent  possible.  PLA’s  must  be  fourteen 
characters  or  less.  Each  newly  added  PLA  is  checked  against  the 
file  to  prevent  duplicate  names  from  occurring. 

When  all  changes,  deletions  and  additions  have  been  completed, 
exiting  from  the  program  will  cause  the  updated  file  to  be  rewritten 
on  the  disk  file  for  use  by  JAMPS  and  for  future  modification. 

3.3.2  Originator  (Prig)  File 

The  opfac  data  can  be  modified  through  the  use  of  a  program 
named  jbldorig.  This  program  operates  in  a  manner  similar  to 
jbldadr  by  use  of  a  displayed  menu  and  appropriate  keyboard  Inputs 
to  control  the  program's  functions. 
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Whenever  a  PLA  is  changed  or  added  to,  as  in  the  case  of  a  new 
entry,  the  Adr  file  is  used  to  verify  a  legal  entry.  PLA's  that  do 
not  appear  in  the  Adr  file  are  rejected.  When  a  new  opfac  is  being 
added  to  the  Orig  file,  the  new  PLA  must  be  added  to  the  Adr  file, 
after  which  it  can  be  used  by  jbldorig. 

3.3.3  Routing  (Rout)  File 

The  data  which  makes  up  the  TO  and  INFO  KDS's  is  found  in  the 
opfac  files,  a  separate  file  for  each  opfac  attached  to  a  JAMPS  sys¬ 
tem.  For  each  message  type  that  can  be  created  and  transmitted  by 
the  system,  a  file  entry  may  exist.  Each  entry  for  a  message  type 
contains,  in  addition  to  the  form  of  the  message  identification,  the 
classification  and  precedences  for  that  message  and  two  lists  of 
PLA's:  one  for  the  TO  addressees  and  the  other  for  the  INFO  address¬ 
ees.  The  number  of  PLA's  is  presently  limited  to  twenty  for  each 
list. 


The  program  jbldrtg  provides  the  means  to  manage  these  files. 
In  a  manner  similar  to  the  other  two  JANAP  programs,  a  menu  and 
instructions  are  displayed  for  operator  use.  All  data  entered  is 
checked  for  validity,  and  error  messages  are  displayed  as  appropri¬ 
ate. 
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SECTION  4 


REBUILDING  THE  JAMPS  DATA  BASE 


In  order  to  use  the  data  in  the  source  files,  the  JAMPS  data 
base  must  be  rebuilt.  The  source  files  which  currently  exist  in  the 
data  base  have  been  written  in  a  combination  of  upper-  and  lowercase 
alphabetic  characters.  Files  which  were  produced  by  programs  ex¬ 
tracting  data  from  the  SDC  print  tape  appear  in  uppercase,  whereas 
files  that  were  generated  by  manual  entry  were  written  in  lowercase. 
Whether  upper  or  lowercase  is  the  preferred  means  of  entry,  all 
files  must  be  converted  to  uppercase  before  they  may  be  converted  to 
object  form.  The  object  file  counterparts  of  the  data  base  source 
files  have  names  ending  in  "dir.i".  The  building  and  maintaining  of 
the  object  files  has  been  automated  in  the  JAMPS  system  by  use  of 
the  UNIX  system's  routine  "makefile".  The  building  routines,  the 
file  interdependencies,  and  the  "makefile"  convention  are  discussed 
in  this  section. 

4.1  Source  Processing  Routines 

The  programs  used  to  build  the  JAMPS  data  base  are  ibid  pro¬ 
grams.  The  ibid  programs  process  the  human-readable  source  files 
and  pack  the  data  in  machine- readable  object  files.  There  are  nine 
Ibid  programs,  one  for  each  type  of  source  file.  Table  2  shows  the 
source  files,  the  processing  ibid  programs  and  the  resultant  object 
files. 
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Table  2.  ibid  Processing  Routines 


.2  File  Interdependencies 


In  rebuilding  the  JAMPS  data  base,  the  order  in  which  the  files 
are  processed  is  important.  The  object  file  mdir.1  is  dependent 
upon  mstrdir.i  and  kstrdir.i,  that  is,  mstrdir.i  and  kstrdir.i  must 
be  built  before  mdir.1  can  be  built.  The  kdlr.1  file  is  dependent 
upon  kstrdir.i,  and  kstrdir.i  must  be  built  before  kdlr.1.  The  rest 
of  the  files  are  totally  independent  of  each  other  and  the  order  in 
which  they  have  been  built. 

4.3  Makefile 


The  process  of  building  and  maintaining  the  object  files  to  be 
used  by  the  JAMPS  system  has  been  automated  by  use  of  "makefile", 
which  allows  the  building  order  of  modules,  libraries  and  interfile 
dependencies  to  be  specified.  The  JAMPS  system  "makefile"  is  named 
precisely  that:  makefile.  Figure  14  shows  makefile  used  to  process 
the  JAMPS  files  into  object  files. 

Before  any  processing  is  done  by  makefile,  all  file  inter¬ 
dependencies  are  scanned  and  checked  to  see  which  of  the  files  have 
been  updated.  Only  the  object  files  specifically  associated  with 
the  updated  versions  of  the  source  files  and  associated  dependent 
object  files,  if  any,  are  updated.  Assume  for  example,  a  change  has 
been  made  to  fdfh.  Rather  than  rebuilding  all  the  message  files, 
mstrdir.i,  kstrdir.i,  mdlr.i,  etc.,  makefile  can  be  used  so  that 
only  fdfh's  object  counterpart,  fdlr.i,  is  updated.  Similarly,  if 
kdslndex  is  revised,  a  call  to  makefile  will  cause  the  rebuilding  of 
kstrdir.i,  kdlr.1  and  mdlr.i.  The  interdependencies  of  the  object 
files  are  included  in  makefile;  the  object  files  to  be  rebuilt  are 
determined  from  the  source  files  that  are  updated,  with  all  building 
taken  place  sequentially. 
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datatables:  mstrdir.i  kstrdir.i  fdir.i  ddir.i  kdir.i  mdir.i  cdir.i  hdir.i\ 
idi r. i 

echo  'ddtd  table  build  and  checkout  complete' 


fdir.i:  fdf h 

-upper  fdfh  cfdfh 
ibid  -i  <cfdfh 
rm  cfdfh 


ddir.i:  dfidui 

-upper  dfidui  cdfi 
ibid  -i  <cdf i 
-rm  ibld.str 
-rm  ibld.tinp 
rm  cdfi 

Kdir.i:  kstrdi r. i  kdss 

-upper  kdss  ckdss 
ibid  -i  <ckdss 
rm  ckdss 

mdir.i:  mstrdir.i  kstrdir.i  catinsg 
sh  catmsg 
-rm  Linsqs 
-upper  msgs  cmsqs 
ibid  -l  <cmsqs 
rm  msgs 

k  st  rdi r. 1 :  kdsindex 

-upper  kdsindex  ckdsindex 
ibid  -i  Cckdsindex 
rm  ckdsindex 

rnsf rdi r. i ;  ms q i ndex 

-upper  msgindex  cmsgindex 
ibid  -i  Ccmsgindex 
rm  cmsgindex 

cdir.i:  codesl  codes2  codes3  codes4 

cat  codesl  codes2  codes3  codes4  >codes 
-ibld7  codes  cdir.i 

hdir.i:  helptextl  helptext2  helptext3  helptext4 

cat  helptextl  helptext2  helptext3  helptext4  >helptext 
-i b! dfi  helptext  hdi r. i 

idir.i:  itemcodel  itemcode2  itemcode3  itemcode4 

cat  itemcodel  itemcode2  itemcode3  itemcode4  >itemcodes 
-ibld9  itemcodes  idir.i 


Figure  14.  makefile 
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The  use  of  makefile  may  be  accomplished  in  two  ways.  The  com¬ 
mand  "make’1  followed  by  an  argument  may  be  used,  or  a  shell  program 
called  makeall  may  be  invoked  by  the  command  "sh  makeall”.  The 
shell  program  makeall  in  turn  issues  the  command  "make",  followed  by 
names  of  the  object  files  that  are  to  be  built,  i.e.,  mstrdir.1, 
kstrdir.i,  mdlr.i,  etc. 

The  arguments  to  the  "make"  command  can  be  the  names  of  any  or 
all  of  the  object  files.  If  all  the  object  files  are  to  be  rebuilt, 
the  argument  "datatables"  may  be  given  rather  than  listing  all  of 
the  object  files  separately.  At  the  end  of  an  editing  session,  the 
easiest  way  to  ensure  that  the  data  base  has  been  properly  rebuilt 
is  by  issuing  the  command  "make  datatables".  If  none  of  the  source 
files  have  been  updated,  the  system  will  respond  with  the  message 
"data  table  build  and  checkout  complete".  The  command  "make  data¬ 
tables"  will  build  only  the  object  files  which  correspond  with,  or 
are  dependent  upon,  the  updated  source  files. 

If  any  of  the  source  files  are  not  properly  completed,  the 
"make"  action  will  be  terminated  with  an  error  message.  By  looking 
at  the  command  given  prior  to  the  error  message,  the  building  rou¬ 
tine  that  returned  the  error  message  can  be  determined.  Likewise, 
by  identifying  the  building  program  that  gave  the  error  message,  the 
erroneous  source  file  may  be  determined. 
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SECTION  5 


CHECKOUT  PROGRAMS 


A  number  of  programs,  the  Iocheck  programs,  have  been  written 
to  aid  in  the  verification  of  the  contents  of  the  object  files.  A 
visual  scan  of  the  output  produced  by  any  of  the  programs  may  be 
performed  to  confirm  accuracy.  All  iocheck  programs  utilize  the 
retrieval  routines  used  by  the  JAMPS  display  management  program  so 
that  the  Iocheck  programs  serve  a  dual  purpose:  verifying  object 
files  and  retrieval  routines.  A  cross  check  program,  xcheck,  has 
also  been  written  to  filter  any  conflicting  data  from  the  source 
files  on  a  message- by-message  basis.  If  there  are  any  conflicts  in 
the  source  file,  an  error  message  is  outputted.  These  programs  will 
be  discussed  in  greater  detail  in  the  following  paragraphs. 

5.1  Input/Output  Check  Programs 

The  input/output  check  programs,  iocheck,  take  as  input  a  mes¬ 
sage  number,  message  index  number,  KOS  name,  KDS  index  number  or 
OF I /DU I ,  depending  on  which  program  is  being  called.  The  output 
produced  from  the  iocheck  programs  has  been  kept  compact.  Gener¬ 
ally,  no  headers  or  identifying  names  are  used  In  presenting  the 
data.  The  Iocheck  programs,  each  object  file  checked,  and  the 
required  Input  are  presented  in  table  3. 

5.1.1  Message  Index  Check 

The  first  input/output  check  program,  iocheckl,  checks  the  ob¬ 
ject  file  mstrdlr.i,  for  accuracy.  Input  to  iocheckl  Is  the  message 
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Table  3 


iocheck  Routines 


iocheck  Programs 

Object  File 

Input 

iocheckl 

■strdir.i 

Message  number  or 
message  index  number 

1ocheck2 

kstrdir.i 

KDS  name  or  KDS  index 
number 

iocheck3 

mdir.i 

Message  name  or 
message  index  number 

iocheck4 

kdlr.1 

KDS  name  or  KDS  index 
number 

iocheck 5 

ddlr.1 
(cdlr.i ) 

DFI/DUI 

1ocheck6 

fdlr.i 

DFI/DUI 

iocheck7 

cdlr.i 

DFI/DUI 

ioc heckS 

hdir.i 

Directional  Indicator 
(0  or  1) 

Idlr.i 

DFI/DUI 
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number  or  message  index  number.  If  the  message  number  is  given  for 
input,  the  output  is  the  message  index  number  and  the  edition  num¬ 
ber.  Therefore,  upon  invoking  "iocheckl  A650",  the  output  Is 
"msgnum  =  2  edition  =  0".  If  iocheckl  is  invoked  using  the  message 
index  number,  the  output  is  the  message  number,  short  message  name, 
message  index  number  and  the  edition  number.  The  output  from 
"iocheckl  2"  is  "A650  APORALOT  20". 

5.1.2  Keyword  Data  Set  Index  Check 

The  KDS  index  check,  1ocheck2,  may  be  invoked  using  the  KDS 
name  or  the  KDS  index  number  as  input.  If  the  KDS  name  Is  given  for 
input,  the  KDS  index  number  and  version  number  is  returned.  The 
command  "iocheck2  6AL0T"  returns  "kdsnum  =  13  version  *  0".  The 
output  returned  when  the  KDS  index  number  is  used  for  input  Is  the 
KDS  name,  the  KDS  index  number  and  the  version  number;  "6AL0T  13  0" 
is  the  returned  output  from  the  command  "iocheck2  13". 

5.1.3  Message  Description  Check 

The  Input/output  check  program,  1ocheck3,  checks  the  message 
description  file.  Input  to  1ocheck3  can  be  the  message  index  number 
or  message  number,  with  the  output  being  the  same  In  either  case. 

The  output  is  in  four  parts  as  shown  in  Tigure  15.  The  first  part 
has  general  information  about  the  message:  the  length  of  the  message 
information  in  bytes,  the  message  number,  the  message  edition  num¬ 
ber,  the  message  index  number,  the  number  of  KDS's  in  the  message, 
the  length  of  the  state  table  in  bytes,  and  the  number  of  prepopu¬ 
lated  field  entries.  The  next  part  of  the  output  Is  the  KDS  table, 
followed  by  the  state  table  and  the  prepopulation  Information. 
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mmsgln  =  712 
mmsgnm  =  A650 
mmeriit  =  0 
mmsgnum  =  2 
mnumkdss  =17 
mstateln  =  75 
mnumman  =  2 


1 

FROM 

0 

1 

0 

1 

1 

0 

2 

TO 

0 

1 

1 

2 

2 

0 

3 

INFO 

0 

0 

1 

3 

3 

0 

4 

CLASS 

0 

1 

0 

7 

4 

0 

5 

SIC 

0 

0 

0 

171 

5 

0 

6 

EXER 

0 

0 

0 

114 

6 

0 

7 

OPER 

0 

0 

0 

146 

7 

0 

8 

MSG  in 

0 

1 

0 

140 

8 

0 

9 

REF 

0 

0 

1 

155 

9 

0 

10 

CANX 

0 

0 

0 

87 

10 

0 

11 

PERIO 

0 

1 

0 

149 

11 

0 

12 

APPOR 

0 

1 

1 

75 

12 

0 

13 

6AL0T 

0 

0 

0 

13 

13 

0 

14 

TGTPRI 

0 

0 

1 

188 

14 

0 

15 

AKNLDG 

0 

0 

0 

71 

15 

0 

16 

RMKS 

0 

1 

0 

6 

16 

0 

17 

OWNGRADE  0 

0 

0 

106 

17 

0 

0 

1  1 

1 

1  2 

2 

3  2 

3 

4 

3 

2  3 

4 

4 

4  5 

6 

7 

8 

5 

3  6 

7 

8 

6  1  8 

7  1  8 

8  3  9  10  11 

9  3  9  10  11 

10  1  11 

11  1  12 

12  5  12  13  14  15  16 

13  3  14  15  16 

14  3  14  15  16 

15  1  16 

16  2  17  -1 

17  1  -1 

4  10SECRU 
8  1  1  APORALOT 


Figure  15.  Sample  Output  from  1ocheck3 
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The  KDS  table  is  not  in  the  same  order  as  it  appears  in  the 
source  file,  nor  does  It  have  an  explanatory  header.  The  first 
column  of  the  table  is  the  KDS  presentation  number.  This  column  is 
followed  by  columns  for  the  KDS  name,  KDS  version,  mandatory  indica¬ 
tor,  repeatability  indicator,  KDS  index  number,  state  number  and 
delete  indicator.  The  mandatory  and  repeatability  indicators  have 
been  replaced  with  "0 1 s"  and  "l's";  "1"  if  mandatory  or  repeatable, 
"0"  otherwise. 

The  KDS  table  is  followed  by  the  state  table.  The  state  table 
is  similar  to  the  source  version  of  the  state  table  minus  the  sepa¬ 
rating  commas,  and  with  the  sharp  sign,  replaced  by  "-1".  An 
additional  column  appears  as  the  second  column  of  the  retrieved 
state  table.  This  column  indicates  the  number  of  states  to  which 
the  associated  state  may  traverse. 

The  table  of  prepopulation  information  is  presented  in  the 
following  order:  KDS  presentation  number,  field  number  within  the 
KDS,  write-protect/unprotect  indicator,  and  the  prepopulation  in¬ 
formation.  Again,  the  write-protect/unprotect  indicators  have  been 
replaced  by  "0's"  and  "l's";  ”1"  for  write- protect,  "0"  for  unpro¬ 
tected.  Again,  the  output  from  the  commands  "iocheck3  2"  or 
“1ocheck3  A650"  are  shown  in  figure  15. 

5.1.4  Keyword  Data  Set  Description  Check 

The  program  to  check  the  KDS  description  files,  1ocheck4,  takes 
as  input  the  KDS  name  or  the  KDS  index  number.  As  in  1ocheck3, 
1ocheck4  will  provide  the  same  output  regardless  of  the  form  of  the 
Input.  The  output  Is  In  three  sections:  a  general  information  sec¬ 
tion,  the  DFI/DU1  table,  and  a  state  table.  The  general  information 
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consists  of  the  length  of  the  KDS  Information  in  bytes,  the  KDS 
name,  the  version  number,  the  KDS  index  number,  the  KDS  type,  the 
number  of  DFI's,  and  the  length  of  the  state  table  In  bytes.  The 
KDS  type  is  represented  as  an  Integer  value;  "1"  represents  a  linear 
KDS,  "2"  represents  columnar,  “3"  represents  freetext  and  "4" 
represents  JANAP. 

Again,  as  with  1ocheck3,  the  DFI/DUI  table  is  not  in  the  same 
order  as  it  appeared  in  the  source  files,  nor  does  it  have  any 
explanatory  headers.  The  order  of  the  table  is  the  presentation 
number  followed  by  the  DFI  type  ("1"  is  for  a  C-type  DFI,  "2"  for  an 
E-type),  the  DFI  number,  DUI  number,  the  columnar  print  position, 
state  number,  mandatory  indicator,  repeatability  Indicator,  manda¬ 
tory  field  descriptor  indicator,  and  the  delete  indicator.  Again, 
"O's"  and  "l1 s"  are  used  for  the  mandatory  and  repeatability  in¬ 
dicators  rather  than  the  "M's"  and  "RV  that  were  used  in  the 
source  files. 

The  state  table  is  similar  to  the  one  that  appeared  in  the 
source  files,  without  the  seoarating  coronas  and  with  the  sharp  sign, 
#,  replaced  by  a  "-1".  As  in  the  state  table  retrieved  by  1ocheck3, 
an  additional  column  Indicating  the  number  of  states  to  which  the 
associated  state  may  go  has  been  added.  Figure  16  shows  the  output 
from  the  commands  " iocheck4  13"  or  "1ocheck4  6AL0T". 

5.1.5  DFI/DUI  Check 

The  check  out  program  for  the  DFI/DUI  file,  1ocheck5,  will  also 
call  upon  the  data  item  codes  file.  This  allows  for  a  more  complete 
picture  of  each  DFI/DUI.  The  Input  to  1ocheck5  Is  the  DFI  type 
("E",  "e",  "C",  or  "c"),  the  DFI  number  and  the  DUI  number,  again, 
no  separation  between  the  DFI  type  and  the  DFI  number  on  input. 
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kkdsln  =  222 
ksetid  =  6M.0T 
kkvers  =  0 
kkdsnum  =  12 
ktype  =  2 

knumdf i s  =2 


kstateln 

1  2  987 

2  2  987 

3  2  107 

4  2  31 

5  2  513 

6  2  987 

7  2  527 


:  30 

31  2 

32  16 
4  30 

22  35 
1  40 

23  47 
1  61 


0  1  1 
1  1  2 

2  1  3 

3  1  4 

4  4  5  6  7 

6  36  7-1 

6  2  7  -1 

7  1  -1 


110  0  0 
2  10  0  0 

3  10  0  0 

4  10  0  0 

5  0  0  0  0 

6  0  0  0  0 

7  0  0  0  0 


-1 


Figure  16.  Sample  Output  from  1ocheck4 
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The  output  of  iocheckB  is  rather  cryptic.  An  example  of  the 
output  from  the  command  “iocheck5  E148  1"  appears  in  figure  17. 

The  first  line  of  output  defines  the  DU  I  indicator.  The  codes 
for  the  DU1  indicators  are  the  following:  “1"  is  chain-type  DFI,  "2" 
is  "COMNOTAB" ,  "3"  is  "C0MTAB\  "4 "  is  "DIFNOTAB" ,  "5"  is  "DIFTAB'' , 
and  "6“  is  "AtTCHN".  The  code  "6"  is  no  longer  in  use.  As  pre¬ 
viously  defined,  a  chain-type  OF  I  is  a  DFI  comprised  of  elemental 
parts.  This  is  denoted  in  JINTACCS  documentation  by  a  "C"  preceding 
the  DFI  number.  A  "COMNOTAB"  is  a  DFI  which  has  been  defined  in  the 
source  files  as  being  a  "com"  type  and  does  not  have  discrete  char¬ 
acter  codes  for  its  OUI's.  A  "COMTAB"  is  a  DFI  which  has  been 
defined  as  a  "com"- type  DFI  in  the  source  file  and  has  discrete 
character  codes  for  the  DUI's.  Likewise  for  "DIFNOTAB"  and 
"DIFTAB".  A  "DIFNOTAB"  is  a  DFI  which  has  been  defined  as  a  "dif" 
type  in  the  source  file  and  has  no  discrete  codes  for  any  of  its 
DUI's.  A  "DIFTAB"  is  a  DFI  which  has  been  defined  as  being  a  "dif” 
type  and  has  discrete  codes  for  its  DUI's.  A  "DIF"  is  a  DFI  which 
has  been  defined  as  being  a  "dif"  type  in  the  source  file  and  some 
of  the  DUI's  have  discrete  codes  and  others  do  not. 

The  next  line  of  the  output  has  the  DFI  type  and  DFI  number, 
followed  by  the  length  of  the  DFI  information  in  bytes  and  the 
number  of  DUI's.  The  entry  for  the  number  of  DUI's  will  be  "-1", 
unless  the  DFI  was  defined  as  being  a  "dif"  type  in  the  source 
files.  In  this  case,  the  number  of  DUI's  will  be  the  number  of 
DUI's  entered  in  the  source  file.  The  next  line,  which  is  only 
entered  if  the  DFI  has  a  number  other  than  "-1"  for  the  number  of 
DUI's  on  the  preceding  line,  identifies  the  DUI  that  is  being 
retrieved. 
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!  I 


dfi  type  =  5 

E148  DIFTA8  ddfiln  =  110  dnumduis  =  2 

DIFTAB  DU  I  =  1 
V  ,L  ,6,33 ,A 

#CHNR0WS  =  -1  #TABRQWS  =  10  STATE  TAB  LN  =  -1  TAB  STR  LN  =  225 


N  A 


T 

0 

P 

S 

E 

C 

RET 

S 

E 

C 

R  E  T 

C 

0 

N 

F 

I 

D 

E 

N 

T 

I  A  L 

R 

E 

S 

T 

R 

I 

C 

T  E  D 

UNCLAS 

N 

A 

T 

0 

C 

0 

S 

M  I  C 

N 

A 

T 

0 

S 

F. 

c 

R  E  T 

T 

0  c 

0 

N 

F 

I 

D 

E 

N 

T 

I  A  L 

N 

A  T  0 

R 

E 

s 

T 

R 

I 

C 

T  E  D 

T 

0  U 

N 

C 

L 

A 

S 

S 

I 

F 

I  E  n 

Figure  17.  Sample  Output  from  1ocheck5 
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The  next  line  presents  the  Information  about  the  DUI  in  the 
same  manner  as  in  dfldul.  The  first  character,  "V"  or  "F",  repre¬ 
sents  variable  or  fixed  field  lengths,  respectively.  The  next 
character  is  the  justification  flag,  "L"  for  left  and  "R"  for  right. 
This  is  followed  by  the  minimum  and  the  maximum  field  lengths.  The 
last  character,  or  characters,  are  the  message  map  codes.  If  only 
one  character  appears,  the  entire  field  is  of  that  type. 

The  next  line  contains  information  pertaining  to  the  number  of 
elements  comprising  a  chain,  the  number  of  codes  for  that  particular 
DFI/DUI,  and  the  length  of  codes  in  bytes.  These  are  indicated  by 
"#CHNR0WS",  "#TABR0WS"  and  "TAB  STR  LN" ,  respectively.  The  indi¬ 
cator  "STATE  TAB  LN"  is  an  artifact  that  was  used  in  handling 
alternate  chains,  which  will  be  stripped  from  the  program  at  some 
future  point.  The  number  of  elemental  DFI's  compressing  a  chain  DFI 
is  the  value  given  for  "ICHNROWS".  The  value  following  "#TABROWS" 
is  the  number  of  codes  for  a  given  DFI/DUI,  whereas  "TAB  STR  LN"  is 
the  length  of  the  code  in  bytes.  The  value  of  these  indicators  will 
be  “-1"  if  it  does  not  apply  to  the  given  DFI/DUI.  For  example,  the 
value  after  "#CHNR0WS"  will  always  be  "-1",  unless  the  DFI  is  a 
C-type  DFI. 

The  information  that  follows  this  will  depend  on  whether  the 
DFI  was  a  C-  or  E-type  DFI.  If  the  DFI  is  a  C  type,  the  next  in¬ 
formation  is  the  elemental  parts  of  the  chain.  If  the  DFI  is  an 
E  type  and  has  discrete  codes,  the  codes  will  be  the  next  piece  of 
information,  otherwise  no  further  information  is  presented. 

5.1.6  Field  Descriptor/Field  Header  Check 

The  program  to  check  the  field  descriptor/field  header  file, 
1ocheck6,  receives  as  input  the  DFI  type  ("E",  "e",  "C",  or  "c"), 
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the  DFI  number  and  the  DUI  number.  There  is  no  separation  between 
the  OF  I  type  and  the  OF  I  number.  The  output  consists  of  the  OF  I 
number,  the  DUI  number,  the  field  descriptor,  and  field  header,  if 
there  is  one.  The  output  from  the  command  "iocheck6  e513  I"  is 
"E513  1  ACTYP  ACTYP " . 

5.1.7  Date  Item  Codes  Check 

The  check  out  program  for  the  data  item  codes  file,  iocheck7, 
has  the  input  of  the  DFI  type  ("E\  "e",  ”C",  or  "c") ,  the  DFI 
number  and  the  DUI  number.  There  should  be  no  separation  between 
the  DFI  type  and  the  DFI  number. 

The  output  from  iocheck7  is  in  two  parts:  the  general  informa¬ 
tion  about  the  DFI /DUI  and  a  list  of  the  valid  code  entries,  if  any, 
for  that  particular  DFI /DUI .  The  general  information  consists  of 
the  number  of  codes,  the  length  in  bytes  of  the  codes,  the  minimum 
code  ltigth,  the  maximum  code  length,  the  range  type,  and  the  lower 
and  upper  bounds  of  the  range.  A  range  type  of  "-1"  indicates  no 
range.  A  range  of  integers  is  indicated  by  a  "1",  "2"  represents  a 
range  of  floating  point  values,  and  "3"  represents  a  range  of  octal 
val ues. 

A  sample  of  the  output  from  the  command  "iocheck7  el 48  1"  is 
shown  in  figure  18. 

5.1.8  Help  Text  Check 

The  program  to  check  the  help  text,  iocheckS,  ensures  the  cor¬ 
rect  processing  of  the  help  text  definitions  and  the  data  items  and 
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E  148  1 

Number  of  Codes  =  10 
Number  of  Bytes  =  225 
Minimum  Code  Length  =  6 
Maximum  Code  Length  =  33 
Range  Type  =  -1 
Lower  Range  Value  =  0 
Upper  Range  Value  =  0 
TOP  SECRET 
SECRET 

CONFIDENTIAL 

RESTRICTED 

UNCLAS 

NATO  COSMIC 
NATO  SECRET 
NATO  CONFIDENTIAL 
NATO  RESTRICTED 
NATO  UNCLASSIFIED 


Figure  18.  Sample  Output  from  1ocheck7 
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data  item  codes  for  a  given  DFI/DUI.  Input  to  1ocheck8  is  the  dir¬ 
ectional  indicator,  the  DFI  type  ("E",  "e",  "C",  or  "c"),  the  DFI 
number  and  the  GUI  number.  The  directional  indicator  can  be  either 
"1"  or  "0";  "1"  for  DFI/DUI  definition  followed  by  data  items  and 
data  item  codes,  or  “0"  for  data  items  and  data  item  codes  followed 
by  the  DFI/DUI  definition.  The  output,  of  course,  is  dependent  upon 
the  directional  indicator.  Figure  19  shows  the  output  from  the  com¬ 
mand  "iocheck8  1  el48  1";  and  figure  20,  output  from  the  command 
“iocheck8  0  el48  1". 

5.2  Cross  Check  Program 


The  program  xcheck  is  used  to  cross  check  the  data  base  on  a 
message-by-messaqe  basis.  This  program  begins  with  the  message 
description  file  and  filters  down  through  all  the  KDS's  within  the 
message  and  all  the  fields  within  the  KDS.  A  check  Is  made  that  all 
entries  necessary  for  the  message  are  there  and  that  there  is  no 
conflicting  information  about  the  message  in  any  of  the  files.  It 
is  worthless  to  run  xcheck  unless  all  the  object  files,  mstrdir.i, 
kstrdir.i,  mdlr.i,  etc.,  have  been  successfully  built  (i.e.,  no 
error  messages  have  been  outputted  when  building  the  files). 

The  following  checks  are  made  by  xcheck  to  verify  the  accuracy 
of  the  message: 

a.  The  message  description  file  for  the  message  to  be  checked 
is  in  the  data  base 

b.  All  KDS's  that  are  referenced  in  the  message  description 
file  have  an  entry  in  kdir.i 

c.  The  OFI's  listed  for  each  KDS  in  a  given  message  have  been 
entered  in  ddlr.i 
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SECURITY  CLASSIFICATION 


DEFINITION:  A  CATEGORY  ASSIGNED  TO  CLASSIFIED  MESSAGE  INFORMATION  OR  MATERIAL. 
ENTER  ONE  OF  THE  COOES. 


TOP  SECRET  MESSAGE  CLAS-  TOP  SECRET 

S  IF [CATION 

SECRET  MESSAGE  CLASSI-  SECRET 

FICATION 

CONFIDENTIAL  MESSAGE  CONFIDENT! 

CLASSIFICATION 

RESTRICTED  MESSAGE  CLAS-  RESTRICTED 

S  IF  1C  AT  ION 

UNCLASSIFIED  MESSAGE  IINCLAS 

CLASSIFICATION 

NATO  COSMIC  NATO  COSMI 


SECRET 

CONFIDENTIAL 


IINCLAS 


NATO  COSMIC 


NATO  SECRET 


NATO  SECRET 


NATO  CONFIDENTIAL 


NATO  CONFIDENTIAL 


NAIO  RESTRICTED 


NATO  RESTRICTED 


NATO  UNCLASSIFIED 


NATO  UNCLASSIFIED 


Figure  19.  Help  Text  Output:  Definition  Followed  by 
Data  Items  and  Codes 
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SECURITY  CLASSIFICATION 

TOP  SECRET  MESSAGE  CLAS¬ 
SIFICATION 

SECRET  MESSAGE  CLASSI¬ 
FICATION 

CONFIDENTIAL  MESSAGE 
CLASSIFICATION 
RESTRICTED  MESSAGE  CLAS¬ 
SIFICATION 
UNCLASSIFIED  MESSAGE 
CLASSIFICATION 
NATO  COSMIC 

NATO  SECRET 

NATO  CONFIDENTIAL 


NATO  RESTRICTED 


NATO  UNCLASSIFIED 


TOP  SECRET 
SECRET 

CONFIDENTIAL 

RESTRICTED 

UNCLAS 

NATO  COSMIC 
NATO  SECRET 
NATO  CONFIDENTIAL 

NATO  RESTRICTED 

NATO  UNCLASSIFIED 


DEFINITION:  A  CATEGORY  ASSIGNED  TO  CLASSIFIED  MESSAGE  INFORMATION  OR  MATERIAL. 


ENTER  ONE  OF  THE  CODES. 


Figure  20.  Help  Text  Output:  Definition  Preceded  by 
Data  Items  and  Codes 
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d.  An  entry  is  found  In  fdir.i  for  each  given  DFI 

e.  All  DFI' s  In  a  linear  KDS  have  a  field  descriptor  entry  in 
fdir.i;  all  DFI's  in  a  columnar  KDS  have  a  field  header 
entry  in  fdir.i 

f.  All  alternate  contents  entries  in  a  columnar  KDS  have  the 
same  field  header  and  print  positions 

g.  In  a  columnar  KDS  with  no  alternate  contents  fields,  no 
field  headers  are  overlapped  by  the  maximum  length  of  the 
preceding  data  field  or  of  the  preceding  field's  header 

h.  The  length  of  the  message  map  characters  equals  the  maximum 
field  length  as  in  ddir.i 

i.  An  entry  is  found  in  hdir.i  and  idir.i  for.  each  DFI/DUI 

j.  An  entry  is  found  In  cdir.i  for  each  DFI/DUI 

k.  The  value  of  the  minimum  and  maximum  code  length  that 
appears  in  cdir.i  falls  within  the  limits  defined  in  ddir.i 

l.  All  E-type  DFI's  comprising  a  C-type  DFI  are  entered  In 
ddir.i 

m.  The  length  of  the  message  map  characters  of  a  C-type  DFI  Is 
equal  to  the  sum  of  the  lengths  of  the  message  map  charac¬ 
ters  of  the  comprising  E-type  DFI’s 

n.  If  a  C-type  DFI  Is  of  variable  length,  at  least  one  of  the 
comprising  E-type  DFI's  is  of  variable  length 

o.  If  a  C-type  DFI  is  of  fixed  length,  all  the  comprising 
E-type  DFI's  are  of  fixed  length 

p.  The  sum  of  the  minimum  field  lengths  of  the  comprising 
E-type  DFI's  In  a  C-type  DFI  equals  the  minimum  field 
length  of  the  C-type  DFI 

q.  The  sum  of  the  maximum  field  lengths  of  the  comprising 
E-type  DFI's  In  a  C-type  DFI  equals  the  maximum  field 
length  of  the  C-type  DFI 
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In  order  it  run  the  xcheck  program,  the  command  "xcheck"  may  be 
invoked,  followed  by  the  message  index  number  or  the  message  number 
of  the  message  that  is  to  be  cross  checked.  If  all  the  messages  in 
the  data  base  are  to  be  cross  checked,  the  command  "xcheckall"  will 
run  xcheck  for  all  the  messages  found  in  mstrdir.i.  If  an  error  is 
found  in  the  object  files,  an  error  message  will  be  outputted. 

5.3  Data  Base  Error  Debugging 

The  error  messages  which  are  outputted  by  xcheck  give  an  indi¬ 
cation  to  where  the  problems  lie  in  the  source  and  object  files. 

When  inserting  messages  into  the  data  base  from  scratch,  it  is 
advisable  to  run  xcheck  one  message  at  a  time  rather  than  using 
xcheckall.  Error  messages  may  be  outputted  with  a  cascading  effect; 
i.e.,  one  actual  error  may  manifest  Itself  as  a  number  of  error 
messages.  In  correcting  the  errors  that  have  been  outputted,  it  is 
advisable  to  handle  them  in  the  order  that  they  are  produced.  This 
is  due,  again,  to  the  cascading  effect  of  the  error  messages;  by 
fixing  the  first  few  occurrences,  all  errors  may  be  eliminated. 

Table  4  shows  the  error  messages  which  are  outputted  from  xcheck, 
the  source  files  that  have  to  be  changed  to  correct  the  error,  and 
the  corrective  actions  to  be  taken. 
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Table  4 


xcheck  Error  Message  Output 


xcheck  ERROR  MESSAGE 

SOURCE  FILE 

CORRECTIVE  ACTION 

***  ERROR  ***  kds  number 
(index  number)  not 
found 

kdslndex 

Add  the  KDS  index  (kds 
number)  to  kdslndex 

***  ERROR  ***  ("E"  or  "C"> 
(DFI)(DUI)  not  found  in 
fdfh  tables 

fdfh 

Make  entry  of  DFI/DUI 
to  fdfh 

***  ERROR  ***  missing 
field  header  ("E"  or  "C") 
(DFI)  (DUI)  set  (KDS  name) 

fdfh 

Enter  field  header  for 
DFI/DUI 

***  ERROR  ***  missing 
field  desc  ("E"  or  "C"! 

(DFD  (DUD  set  (KDS  name) 

fdfh 

Enter  field  descriptor 
for  DFI/DUI 

***  ERROR  ***  All  A/C 
print  pos's  must  be 
identical:  ("E"  or  “C") 

(DFD (DUD  set  (KDS  name) 

kdss 

Change  print  position 
entries  so  all  are  same 
in  kdss 

***  ERROR  ***  All  A/C  fid 
hdrs  must  be  identical : 

("E"  or  "C")  (DFD  (DUD 
set  (KDS  name) 

fdfh 

Change  entry  in  fdfh  so 
all  field  headers  are 
for  alternate  contents 
fields 

***  ERROR  ***  Prior 
field’s  max  of  (maximum 
field  length)  >  field 
space  of  (field  space  from 
print  positions)  ("E"  or 
"C")  (DFD  (DUD  set 
(KDS  name) 

kdss 

dfldui 

Determine  if  error  is 
in  the  maximum  field 
length  entry  in  dfldui 
or  ir.  the  print  posi¬ 
tion  in  kdss  (only 
appears  in  columnar 
sets) 

***  ERROR  ***  Prior  fields 
header  length  too  long  for 
field:  ("ES  or  "C")  (DFD 

fdfh 

kdss 

Determine  if  problem  is 

field  heacier  or  print 
position 

(OU1)  set  (KDS  name) 


Table  4  (Continued) 
xcheck  Error  Message  Output 


xcheck  ERROR  MESSAGE 

SOURCE  FILE 

CORRECTIVE  ACTION 

***  ERROR  ***  ("E"  or  "C") 
(DFI)  (DU1 )  in  set  ( KDS 
name)  not  found  in  dfi 
tables 

dfidui 

Make  DFI /DU I  entry  to 
dfidui 

***  ERROR  ***  msg  map 
lngth  (length  of  msg  map) 

!  =  field  max  (max  field 
length)  in  ("E"  or  "C") 

(DFI)  (Dili )  set  (KDS  name) 

dfidui 

Fix  message  map  or 
maximum  field  length, 
whichever  is  in  error 

***  ERROR  ***  request  error 
in  gethelp  ask  ((“E"  or  "C")) 
(DFI)  (DUI )  got  (("E"  or  "C")) 
(DFI)  (DUI) 

hdir.i 

FATAL  ERROR  -  consult 
system  engineer  (should 
not  occur! ) 

***  ERROR  ***  ("E"  or  "C") 

(DFI)  (DUI)  in  set  (KDS 
name)  caused  error  return 
in  gethelp 

hdir.i 

FATAL  ERROR  -  consult 
system  engineer  (should 
not  occur! ) 

***  WARNING  ***  missing  help 
in  hdir.i  ("E"  or  "C") 

(DFI)  (DUI)  in  set  (KDS  name) 

helptext 

Make  addition  in  text 
helptext  for  missing 

DFI /DU I 

***  WARNING  ***  Missing  data 
item/codes  in  idir.i  ("E"  or 
"C")  (DFI)  (DUI)  in  set  (KDS 
name) 

itemcodes 

Make  addition  in 
itemcodes  for  missing 
DFI /DUI 

***  WARNING  ***  missing 
entries  in  hdir.i  of  idir.i 
("E"  or  "C”)  (DFI)  (DUI)  in 
set  (KDS  name) 

helptext 

1 temcodes 

Make  addition  to 
helptext  and  Itemcodes 
for  missing  DFI/DUI 

***  ERROR  ***  dberr  detected 
in  retrieving  E  (DFI)  (DUI) 
in  set  (KDS  name)  from  data 

idir.i 

FATAL  ERROR  -  consult 
system  engineer  (should 
not  occur!) 

item  code  tables 


Table  4  (Continued) 
xcheck  Error  Message  Output 


xcheck  ERROR  MESSAGE 

SOURCE  FILE 

CORRECTIVE  ACTION 

***  WARNING  ***  E  (DPI) 

(DUI)  in  set  (KDS  name) 
missing  from  cdir.i 

codes 

Make  addition  to  codes 
for  missing  DF1/DUI 

***  ERROR  ***  requested  E 
(DFI )  received  E  (DPI ) 

cdir.i 

FATAL  ERROR  -  consult 
system  engineer  (should 
not  occur! ) 

***  ERROR  ***  Bad  maxlen 

E  (DFI)  (DUI)  set  (KDS  name) 
actual  =  (max.  field  length) 
specified  =  (max.  code  length) 

dfidui 

codes 

Determine  if  error  is 
maximum  field  length 
entered  in  dfidui  or 
one  of  the  codes 

***  ERROR  ***  Bad  minlen 

E  (DFI)  (DUI)  set  (KDS  name) 
actual  =  (min-  field  length) 
specified  =  (min.  code  length) 

dfidui 

codes 

Determine  if  error  is 
minimum  field  length 
entered  in  dfidui  or 
one  of  the  codes 

***  ERROR  ***  component  E 
(DFI)  (DUI)  of  C  (DFI)  (DUI) 
not  found  in  dfi  tables 

dfidui 

Make  entry  to  dfidui 
for  missing  DFI/DUI 

***  ERROR  ***  C  (DFI)  (DUI) 
is  f  type  E  (DFI)  (DUI) 
is  v  type 

dfidui 

Change  C-type  DFI  to 
variable  or  E-types  to 
fixed 

***  ERROR  ***  C  (DFI)  (DUI) 
v  type ,  all  E ' s  are  f 
type 

dfidui 

Change  C-type  DFI  to  is 
fixed  or  E-type  DFI's 
to  variable 

***  ERROR  ***  C  (DFI) 
map  =  (length)  not  equal 
to  sum  E  map  =  (length) 

dfidui 

Determine  if  rrror  is 
C-type  OF I  message  map 
or  E-type  DH‘s  message 
map 

***  ERROR  ***  C  (DFI) 

(length)  not  equal 
to  sum  E  max  =  (length) 

dfidui 

Determine  if  error  is 
max  =  maximum  length  of 
C-type  IF  I  or  maximum 
length  or  t.-type  DCI 
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Table  4  (Concluded) 
xcheck  Error  Message  Output 


xcheck  ERROR  MESSAGE 

SOURCE  FILE 

CORRECTIVE  ACTION 

***  ERROR  ***  C  (DPI) 

dfidui 

Determine  if  error  is 

min  =  (length)  not  equal 

minimum  length  of  to 

sum  E  min  =  (length) 

C-type  or  minimum 
length  of  E-type  DFI 

SECTION  6 


SOURCE  DOCUMENTS 


This  section  describes  the  source  documents  used  to  create  and 
make  changes  to  the  data  base.  The  three  primary  documents  are  the 
Technical  Interface  Design  Plan  (TIDP),  the  Catalog  of  Data  Sets, 
and  the  Message  Element  Dictionary  (MED).  Each  of  these  sources  is 
described  in  the  following  paragraphs. 

6 . 1  Technical  Interface  Design  (TIDP) 


The  TIOP,  which  is  a  classified  document,  contains  descriptions 
of  each  of  the  JINTACCS  messages.  Figure  21  is  a  typical  page  from 
the  TIDP,  and  shows  the  makeup  of  the  APORALOT  message.  The  first 
main  text  line  of  the  figure,  entitled  MESSAGE  NUMBER,  gives  the 
message  number,  A650  and  short  message  name  for  the  APORALOT  mes¬ 
sage.  The  next  line  of  this  figure  gives  the  full  name  or  title, 
Apportionment/Allotment  message.  Following  the  general  description 
of  the  purpose  of  this  message,  as  shown  in  this  figure,  is  a  list 
of  the  keyword  data  sets  for  this  message  under  the  column  heading 
SET  IOENT.  Since  this  message  actually  covers  three  pages  in  the 
TIDP,  only  a  portion  of  the  KDS's  are  shown  in  this  figure.  Those 
that  are  shown  are  the  standard  introductory  sets  which  are  con¬ 
tained  in  all  messages. 

Two  of  the  standard  introductory  data  sets,  EXER  ana  OPER,  have 
restrictions  on  their  use  which  are  not  snown  in  figure  21.  figure 
22  is  an  extract  from  part  of  the  special  instructions  contained  in 
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UNCLASSIFIED 


JIHTACCS  TIDP-TF. 


Volume  Vl 
R1 

MESSAGE  INSTRUCTIONS  (U)  Page  2  of  A 

'“HSSAGF  NUMBER:  Al  ]  JI  NT  ACCS  Character-Or  Jented  Messages  (U) 

Standard  Introductory  Sets  (SIS]  (U) 

spECl.V  INSTRUCTIONS  (continued)  (U) 

:r*  Set  Identifier:  (CLASS)  (M)  (continued) 

b.  For  NATO  messages,  use  only  those  data  items  and  codes 
listed  under  the  heading  of  "SPECIAL  HANDLING"  (DFI 
"E587.  DUI  001). 

■  1  ’  Special  Identifier:  SIC  (C).  The  use  of  this  set  is  mandatory  to 
<je!  in*-  th*.  sublet:  mutter  of  the  message  when  attached  to  NAT" 

.m.m.i  ic. .  This  set  is  not  used  in  intra-D.S.  messages.  Note  that 
thi  re  n«  ficlo  marker  following  the  set  Identifier.  An  end  of 
**i  t  mar^or  is  not  used  with  this  set. 

r  i  •  .  NA<IC  Code  [V].  F.ntor  the  appropriate  NAS1S  code  as 

determined  from  NATO  Supplement  2  to  ACP  121.  (DFI  #E332, 

DUI  001). 


.  NASIS  Code  ( 0 ,  R  ]  .  The  NAS1S  code  field  is  repeated  as 
necessary  to  describe  the  message  contents  (DFI  IE332,  UUl 

001)  . 

Set  Identifier:  EXER  ( C ] -  This  set  is  conditional  upon  the 
message  oeing  applicable  to  an  exercise.  S0t  la  Mt  «m4 

for  operational  purpoaaa  or  If  an  nt  la  mmi. 

1.  Exercise  Nickname  (Mj.  Enter  the  code  name  or  nickname  of 
the  exercise  to  which  the  message  pertains  (DFI  #E335,  DUI 
(Kill. 

fjel.  2,  Exercise  Message  Additional  Identifier  [0].  Enter  an 

additional  exercise  nickname  or  identifier  (DFI  #E33b,  DUI 

ofu- )  . 


•  et  identifier:  OPER  [C).  This  set  is  conditional  upon  the 
■nes sage  being  applicable  to  an  operation  that  has  a  code  name  or 
n . ; kname .  It  is  not  used  if  an  operation  name  has  not  been 

**s  t  a*- 1  i  shed .  and  It  1«  mt  mmi  WifllM  pTfOP—  OT  If  tfc# 

set  "EXSB"  ia  uaad. 

*!•  !.  'petat  »<m  Codeword  (M].  Enter  the  assigned  operation  name 

•  >r  nickname  as  established  by  appropriate  authority  (DFl 

•E3.1A.  '  IT  0u  1  >  . 


2-1 


S 


UNCLASSIFIED 

Figure  22.  Extraction  of  Message  Instructions  from  TIDP 
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the  TIDP.  From  these  instructions  it  is  seen  that  EXER  and  OPER  are 
mutually  exclusive,  that  is,  if  one  is  used,  the  other  cannot  be 
used  in  that  message  even  though  the  category  for  the  two  KDS's 
listed  in  figure  21  shows  both  KDS's  as  being  mandatory.  It  is  im¬ 
portant  that  all  special  instructions  of  the  HOP  are  checked  before 
attempting  changes  to  the  data  base. 

Continuing  with  the  description  of  the  APORALOT  message  as 
found  in  the  TIDP,  figure  23  provides  the  list  of  KDS's  that  form 
this  message  and  are  not  part  of  the  standard  introductory  set.  As 
shown  in  this  figure  under  the  SET  IDENT  column  heading,  the  first 
KDS  is  CANX.  Moving  to  the  next  column,  the  "C"  on  the  same  line  is 
the  KDS  for  the  category  for  that  KDS,  which  in  this  case  is  condi¬ 
tional.  The  next  KDS,  PER1D,  has  an  "m"  in  this  column,  making  that 
KDS  mandatory.  The  APORALOT  KDS  is  listed  in  this  column  as  both 
mandatory  and  repeatable. 

Following  in  this  category  column  are  individual  qualifiers  for 
each  field  within  a  KDS.  In  the  case  of  CANX,  there  are  a  total  of 
seven  fields  as  shown  in  the  next  column,  the  first  four  of  which 
are  mandatory  and  the  last  three  are  optional.  For  the  APORALOT 
KDS,  fields  3  and  4  have  been  designated  both  mandatory  and  repeat- 
able.  The  KDS  6AL0T  is  an  example  of  the  columnar  KDS  identified  by 
the  numerical  prefix  to  its  name.  In  the  column  to  the  right  of  the 
field  numbers  of  this  KDS  are  the  nine  column  headers  that  will  ap¬ 
pear  in  this  message.  The  interpretation  of  data  in  the  "MANDATOR V 
ENTRY/FLO  DESC/COL  HEADER"  column  can  easily  lead  to  confusion. 

When  data  appears  in  this  column  and  the  associated  KDS  is  columnar, 
the  data  is  column  header.  For  linear  KDS's,  data  entries  in  this 
column  ending  with  a  colon  are  field  descriptors  and  will  pre¬ 
cede  the  field  in  the  message.  A  linear  entry  without  the  colon  is 

a  mandatory  entry  for  that  field. 
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Figure  23.  TIDP  Message  Definitions 


Figure  24  is  part  of  the  message  map  for  the  A650  message.  The 
line  following  the  title  line  is  there  for  convenience  of  deter¬ 
mining  the  length  and  starting  position  of  any  field  within  the 
message.  The  map  itself  begins  on  the  line  following  this  index. 
That  line  is  the  classification  KDS,  showing  it  is  two  fields.  The 
first  field  is  three  characters  of  alphabetic  information,  and  after 
a  single  blank,  a  thi rty-character  field,  also  of  alphabetic  infor¬ 
mation.  The  seventh  line  in  this  map  shows  the  format  for  the  MSG1D 
KDS.  Field  1  of  this  KDS  is  shown  filled  in  with  a  mandatory  entry, 
the  message  name,  APORALOT. 

Returning  briefly  to  figure  21,  and  checking  the  MSGID  KDS  in 
field  1,  a  mandatory  entry  is  shown.  This  data  must  appear  in  the 
message.  The  last  field  in  the  MSGID  KDS  consists  of  three  numeri¬ 
cal  characters  as  specified  by  the  "nnn"  in  the  message  map.  The 
message  map  shown  in  figure  25  provides  an  example  of  a  columnar 
data  set  and  how  it  should  appear  in  the  message.  The  6AL0T  KDS  is 
shown  with  the  seven  column  headers  that  appear  in  this  KDS,  as 
shown  in  figure  23.  An  alternate  contents  field  is  shown  in  figure 
25.  Field  2  of  TGTPRI  KDS  has  four  alternate  entries  that  can  be 
used  for  this  field,  each  of  different  lengths. 

6.2  Catalog  of  Keyword  Oata  Sets 


The  Catalog  of  Keyword  Data  Sets  is  an  extract  of  information 
from  the  TIDP.  When  making  additions  to  the  JAMPS  data  base,  either 
the  TIDP  or  the  Catalog  of  Keyword  Data  Sets  may  be  used  as  the  in¬ 
formation  source.  The  advantage  of  using  the  Catalog  over  the  TIDP 
is  that  the  Catalog  is  not  classified,  and  as  such  is  more  conve¬ 
nient. 
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Figure  24,  TIDP  Message  Map 


Figure  25.  TIDP  Message  Map  Showing  Alternate  Contents  Field 
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A  page  from  the  Catalog  of  Keyword  Data  Sets  is  reproduced  in 
figure  26.  The  KDS  name  can  be  found  in  the  column  designated  SET 
IDENTIFIER,  and  in  this  example  is  ACLOST. 

The  KDS  description  contains  a  map  similar  to  that  for  the 
message  description  found  in  the  TIDP  (see  figure  24).  In  this 
example,  two  of  the  fields  (fields  4  and  S)  have  alternates.  When  a 
field  of  a  KDS  has  alternates,  the  longest  field  size  is  shown  in 
the  map,  and  all  choices  are  shown  below  in  their  proper  size  and 
with  the  proper  data  designators.  For  field  S,  the  five  alternates 
range  in  size  from  a  length  of  eight  alphanumeric  characters  to  a 
maximum  of  twenty. 

following  SET  MAP,  as  shown  in  this  figure,  is  SET  CONTENT. 

This  portion  of  the  figure  defines  the  category  of  each  field.  The 
meanings  here  are  the  same  as  used  for  messages  discussed  earlier. 

An  "M"  is  a  mandatory  entry,  an  "R"  signifies  repeatable,  and  a  "C" 
is  conditional.  (Note  that  when  building  a  data  base  for  JAMPS,  a 
"C"  is  never  entered;  a  blank  is  interpreted  as  conditional.) 

The  three  columns  to  the  right  of  the  category  column  give  the 
DFI/DUI  number  of  the  element.  The  "NO/TYPE"  column  specifies  the 
number  of  characters  in  the  field,  both  a  minimum  and  a  maximum  can 
be  specified,  and  the  data  type.  The  data  types  presented  in  the 
SET  MAP,  however,  are  more  accurate  and  should  be  used. 

An  example  of  a  columnar  KDS  from  the  Catalog  is  given  in 
figure  27.  The  set  of  column  headers  as  listed  in  the  TIDP  for  a 
message  using  this  KDS  are  shown  in  their  proper  orientation  In  the 
"SET  MAP". 
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Figure  26.  Typical  Page  from  Catalog  of  Keyword  Data  Sets 
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Figure  27.  Columnar  KDS  from  Catalog  of  Keyword  Data  Sets 


The  remainder  of  the  information  is  as  described  for  a  linear 
KOS  in  the  preceding  paragraphs,  except  for  the  "J"  column  of  the 
"SET  CONTENT"  section.  For  a  columnar  KDS,  the  "J "  column  contains 
an  "l"  or  an  "R"  for  left  or  right  justification  of  the  field  entry. 

6.3  Message  Element  Dictionary  (MED) 


The  MED  extract  contains  all  necessary  information  relating  to 
elements  which  make  up  the  KDS's.  The  MED  is  extracted  from  a  spe¬ 
cific  volume  of  the  TIDP,  in  this  case  Volume  IV,  and  contains  only 
those  DFI/DUI's  that  are  referenced  by  that  volume  of  the  TIDP. 

There  are  two  basic  types  of  DFI/DUI's  to  be  considered.  First 
is  the  chain  type,  identified  by  the  starting  letter  "C".  Figure  28 
is  a  page  from  the  MED  describing  a  chain- type  DFI/DUI,  in  this  case 
C  143,  which  has  as  its  DF I  name,  Military  Day-Time.  The  elemental, 
or  "E"-type,  DFI/OUI's  which  make  up  this  chain  are  listed  in  the 
central  part  of  this  figure,  and  consist  of  four  elements.  For  each 
element,  its  DFI  and  uUI  numbers  are  given,  as  well  as  the  DU  I  name. 
In  the  right-most  column,  the  length  of  each  field  is  provided,  and 
the  type  of  data  to  be  used.  For  example,  the  first  element  is  E 
023,  and  its  DUI  number  is  001.  The  element  name  is  Day,  and  the 
field  consists  of  two  numeric  characters. 

Following  the  description  of  each  DFI/DUI  is  a  set  and  message 
applicability  section.  This  information  for  the  C  143  DFI  is  shown 
in  figure  29.  Information  is  presented  here  for  each  DUI  of  the 
DFI.  In  this  figure  the  applicable  messages  for  DUI 1 s  001,  002,  003 
and  005  are  listed.  For  DUI  005,  there  are  two  KDS's  which  refer¬ 
ence  the  DFI,  the  first  being  CANX,  and  the  second,  REF.  This 
provides  a  complete  cross  reference  from  chain- type  DFI's  to  KDS's 
to  messages. 
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An  elemental,  or  "E"-type  OFI  is  shown  in  figure  30.  A  DFI 
refers  to  a  family  of  related  items.  Each  item  is  distinguished  by 
a  different  DUI  number.  In  this  example,  the  root  of  the  family, 
i.e.,  the  OFI,  is  named  "Percentage".  The  four  DUI's  of  this  family 
shown  in  the  figure  are  "PERCENTAGE",  "PERCENT  DAMAGE",  "PERCENT 
DESTROYED"  and  "PERCENT  COVERAGE",  respectively.  Each  of  the  four 
DUI's  is  specified  to  be  one  to  three  numerical  characters  in 
length,  and  right-justi fied  in  their  use. 

Some  of  the  DFI's  have  specified  data  entries  that  can  be  made 
in  the  field.  Figure  31  is  an  example  of  an  elemental  DFI  that  has 
a  defined  set  of  codes  that  can  only  be  used  when  filling  the  defin¬ 
ed  field.  In  this  example,  the  columns  "DATA  ITEM"  and  "CHAR  CODE" 
provide  a  guide  to  what  may  be  entered  in  the  field. 
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APPENDIX  A 


Tutorial:  Adding  a  JINTACCS  Message  to  the  JAMPS  Data  Base 


The  most  complex  revision  to  the  JAMPS  data  base  is  the  addi¬ 
tion  of  a  message,  therefore,  once  this  skill  is  mastered,  data  base 
revision  is  mastered.  This  section  describes  the  step-by-step  pro¬ 
cedure  for  entering  a  message  into  the  data  base.  The  assumption 
will  be  made  that  no  parts  comprising  the  message  presently  exist  in 
the  data  base.  The  Approtionment/ Allotment  (APORALOT)  message, 

A650,  will  be  used  in  this  tutorial. 

The  first  step  is  to  determine  the  message  name,  short  message 
name  and  message  number,  which  can  be  found  in  the  TIDP.  The  mes¬ 
sage  number  and  short  message  name  appear  on  the  first  line  of  the 
message  content.  The  message  name,  or  message  title,  follow  on  the 
next  line.  When  inserting  a  message  to  the  data  base,  the  message 
name  should  appear  on  the  message  menu  used  in  the  JAMPS  display. 
Although  this  Is  not  an  advertised  part  of  the  data  base.  It  should 
be  kept  up-to-date  to  avoid  operator  confusion.  The  Air  Operations 
messages  used  In  the  JAMPS  message  menu  are  found  In  the  file, 
alrops.db.  As  other  categories  such  as  Intelligence,  Operations 
Control,  Amphibious,  and  Fire  Support  are  added  to  the  JAMPS  data 
base,  additional  message  menus  will  also  be  added.  Pictured  In  fig¬ 
ure  A-l  is  the  alrops.db  file  prior  to  the  addition  of  the  APORALOT 
message.  The  message  number,  short  message  name  and  long  message 
name  should  be  entered,  using  the  same  format  as  existing  entries. 
This  file  must  have  record  lengths  of  80  characters.  The  carriage 
return  character  must  appear  in  column  80,  and  no  tab  characters 
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Figure  A-l.  airops.db  File  in  Raw  Mode  Before  Insertion  of  A650 


should  appear  In  the  file.  Presently  this  must  be  accomplished  by 
manually  editing  the  file.  At  some  point,  a  shell  program  will  be 
written  which  will  provide  automatic  reformatting  of  this  table. 

Upon  entering  the  message  Information  for  the  APORALOT  message 
to  alrops.d),  the  number  of  records  appearing  In  the  header  line  of 
the  alrops.db  file  must  be  updated  to  account  for  the  Increase  In 
size  due  to  the  added  record.  The  updated  alrops.db  file  appears  In 
figure  A-2.  Note  the  carriage  return  character  which  appears  as  a 
"t"  sign  In  raw  mode  In  column  80,  and  the  update  of  number  of  re¬ 
cords  in  the  header  line. 

Next,  the  msglndex  file  must  be  updated  to  Include  the  APORALOT 
message.  Figure  A-3  depicts  the  msglndex  file  before  Insertion  of 
the  APORALOT  message.  The  Information  to  be  entered  In  msglndex  Is 
the  short  message  name,  the  message  number  and  the  message  Index 
number.  There  is  a  long-range  plan  to  Incorporate  the  use  of  an 
edition  number  along  with  the  messages.  This  will  allow  different 
editions  of  the  same  message  to  exist  In  the  data  base.  The 
msglndex  number  is  the  next  sequential  number  In  the  list.  Keeping 
the  same  format  as  existing  data  In  the  file,  the  message  number, 
the  short  message  name,  and  the  msglndex  number,  all  separated  by 
commas,  are  entered  Into  the  data  base.  For  trackablllty,  comments 
may  be  Inserted  following  the  entry.  These  comments  can  provide 
explanations  for  the  entry  (e.g.,  "Revision  to  the  TIDP",  or 
"Developmental  Interface  Change  Proposal  (DICP)").  The  completed 
msglndex  entry  Is  shown  In  figure  A-4. 

All  the  message  description  files  are  required  to  be  concatena¬ 
ted  Into  a  single,  file  before  processing  the  data  base  Into  object 
flies.  An  entry  must  be  made  to  the  catmsg  file  so  that  the  message 


87 


jas.: 


00 

0) 

CT 

cr 

r> 

4-> 

0) 

to 

<r 

u 

to 

o 

cn 

to 

UJ 

Q. 

<o 

0) 

o 

Of  4-> 

</> 

ac 

CO 

or  0)  fi- 

i/)  0) 

*3- 

cn  o 

QJ  C71 

0) 

tO  <Q  Q. 

s:  os 

4-) 

O! 

0J 

co 

3  10  0) 

01 

to 

03 

<D 

CVJ 

4->  IO  O' 

i— 

4->  tO 

C5 

to 

O) 

<0  CD 

3 

c  0) 

to 

to 

h  h  E  h 

T3 

q?Z 

»— 

0J 

to 

■*■»  X3 

i-  o  c 
ai  ■—  <o 
■D  ■—  E 
t_  +J  «r  E 

O  D 

0J  4J  O 
x:  =s  e 
u  crti  ti 
C  01  E  1/1 
3  o:  c  c 
n>  o  a> 

_J  4->  <*- 

<*-■»->  0) 
4->  M—  fi-  Q 
L  r-  O 
oj  l  a  l 
—I-  Q. 

<  <c  c  < 


C  ^  ^ 
jc  a  u  u 
<j  <o  <o  m 

0;  L  L  L 


h-  QC 

LU  <  <  H-  O  I 

Oh  3  z  O  < 

Z  1/1  U.  UJ  o  CO 

<iuj>dzoc« 

X<QU 

uwaazioa; 

<<<<<•*<<• 


i  ro  Hr- ioooo 

OOOH  h 

t/)NrsfxNiOVONVO»ON 
£CQQ0UIC0U.U.<O<UJ 


<  —I 
o  uj 

o_  t—  z  a_ 
OZ<UJ 
ZC  Z  QC 

uy  y  ^ 

UJ  Q£  0C  Q£ 


f-4  m  cvj  ro 
in  m  m 
<ONhh 
<  u.  m  u. 


'  V  v:-  . 


Figure  A-2.  airops.db  File  in  Raw  Mode  After  Insertion  of  A650 


•msg index 


;  field  order  is  as  follows: 


message  number 
short  message  name 
message  index  number 

edition  number  (blank  will  be  interpreted  as  edition  0) 


d669 , jsarreq,  1 
a653,crossdat,  2 
a66 1 , reqstatask ,  3 
3690 , tacopdat ,  4 
a691,techopdat,  5 
a770,alord,  6 
b702 , jlnchrep,  7 
b703,airevent,  8 
b704,abchange,  9 
b705,acsamstat,  10 
b711,engsts,  11 
b750,jinflt,  12 
c001 ,  msgchange  rep,  1 3 
c420,sarsit,  14 
c4B2,sarir,  15 
>3600,  jcasintreg,  16 
d660, jairreq,  17 
d630,alreg,  18 
d667, jrecreq,  19 
d666, jescreq,  20 
d668, jsupreq,  21 
e706, inithand,  22 
f625,reqconf,  23 
e707 , rechand ,  24 
e710,airdefoom,  25 
f632, fltcontinfo,  26 
e715,airdefwarn,  27 
f54l,aknldg,  28 
f63L,almsnso3,  29 
f654,crossoonf ,  30 
f753,trkrep,  31 
f754,fltpln,  32 
f750,desigarea,  33 
f75l,eandat,  34 
a65l .enployaloc,  35 
a652,sortalot,  36 
f752,trkman,  37 
a635,heloaldat,  38 
f636,heloalconf ,  39 
d665, jairsupreq,  40 
f755,trkintel,  41 
c460 , cams pot ,  42 


Figure  A-3.  tasglndex  Prior  to  Insertion  of  A650  Message 


.msgindex 


field  order  is  as  follows: 

message  nurrber 
short  message  name 
message  index  nurrfoer 

edition  nurrber  (blank  will  be  interpreted  as  edition  0) 


d669 , jsarreq. 

1 

a653,crossdat. 

2 

a661 , reqstatask. 

3 

a690,tacopdat. 

4 

a691 , techopdat , 

5 

a77g,alord. 

6 

b702, jlnchrep, 

7 

b703 . airevent , 

8 

b704 , abchange , 

9 

b705 , aesamstat , 

• 

10 

• 

* 

d665, jairsupreq, 

40 

f755,trkintel, 

41 

c460 , cams pot , 

42 

a650,aporalot, 

43 

Figure  A-4.  APORALOT  Message  in  asglndex 


description  file  to  be  created  for  the  APORALOT  message  will  be  con¬ 
catenated  along  with  the  other  files.  The  catmsg  file  appears  In 
figure  A-5.  Again,  this  file  requires  an  entry  of  the  short  message 
name,  using  the  format  existing  In  the  file.  The  new  catmsg,  with 
the  APORALOT  message  entered.  Is  shown  In  figure  A-6. 

The  next  step  is  to  create  the  message  description  file  for  the 
APORALOT  message.  The  TIOP  contains  all  the  Information  needed  to 
create  this  file.  The  name  of  the  file  to  be  created  Is  aporalot, 
the  short  message  name.  The  first  entry  Is  ".msg",  followed  by  the 
message  number.  The  next  entry  is  ".edition",  followed  by  the  edi¬ 
tion  number,  in  this  case  "0".  Even  in  updating  a  message,  the 
edition  number  is  kept  at  "0". 

Most  message  description  files  have  comments  inserted  which 
outline  the  format  of  the  table  used  In  part  two  of  the  file.  It  Is 
recommended  that  comments  be  used  to  define  the  table  and  provide 
easier  readability. 

The  first  three  sets  to  be  entered  In  the  table  are  common  to 
every  message  and  therefore  to  every  message  description  file.  The 
FROM,  TO,  and  INFO  KDS's  are  used  for  the  JANAP  header  information. 
According  to  JINTACCS  rules,  any  Information  which  can  be  trans¬ 
mitted  must  be  framed  using  JANAP  128  headers  and  trailers.  The 
Initial  entry  to  APORALOT  Is  pictured  In  figure  A-7.  The  FROM  and 
TO  sets  are  mandatory;  TO  and  INFO  sets  are  repeatable. 

Following  the  JANAP  header  Information,  entries  to  be  made  to 
the  table  are  the  keyword  data  sets  appearing  In  the  TIOP  for  the 
APORALOT  message.  The  KDS  name  appears  In  the  left-most  column  of 
the  TIOP  under  the  heading  "SET  IDENT".  The  mandatory  and  repeat- 
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Figure  A-5.  catmsg  Before  Insertion  of  A650  Message 
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cat\ 
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Figure  A-6.  APORALOT  Message  Inserted  into  catnsg 
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.msy  a650 
.edition  0 

;  field  order  is  as  follows: 

;  presentation  number  of  keyword  data  set 

:  keyword  data  set  name 

;  state  number 

r  mandatory  indicator  (m  or  M,  if  mandatory) 

;  repeatability  indicator(r  or  R,  if  repeatable) 

;  version  number  (optional,  blank  will  use  most  recent  version) 

r  delete  indicator  (l=delete  on  input, 2=delete  on  output, 3=delete 

;  input  and  output,  blank  or  0=used  for  txoth  input  and  output) 
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Figure  A-7.  JANAP  Sets  Entered  into  aporalot 


ability  indicators  appear  on  the  same  line  as  the  KDS  name,  but 
under  the  column  headed  "CAT".  Only  mandatory  and  repeatability 
conditions  are  reflected  in  the  KDS  table,  not  conditionality,  as 
represented  by  a  "C"  in  the  TIDP.  The  version  number  and  delete 
indicator  entries  are  left  blank. 

The  presentation  number  is  the  number  which  represents  the  lo¬ 
cation  of  the  keyword  data  set  in  the  message;  i.e.,  the  third  KDS 
has  a  presentation  number  of  "3",  etc.  In  general,  the  presentation 
number  is  the  same  as  the  state  number;  however,  this  need  not  be 
the  case.  This  will  be  discussed  in  greater  detail  later  in  this 
tutorial.  The  completed  entry  for  the  KDS  table  for  the  APORALOT 
message  is  pictured  in  figure  A-8. 

A  state  table  is  then  built  by  combining  the  information 
displayed  in  the  keyword  data  set  table,  the  message  content  as 
displayed  in  table  form  in  the  TIDP,  and  the  descriptive  text  in¬ 
formation  from  the  TIDP.  The  first  entry  for  the  state  table  is  the 
mandatory  ".state"  token,  followed  by  the  body  of  the  state  table. 

The  state  table  uses  the  state  numbers  as  established  by  the 
keyword  data  set  table,  and  the  sharp  sign,  "#",  which  represents 
the  end  of  the  message.  The  table  begins  from  a  state  of  "0",  the 
start  state.  From  "0",  the  FROM  set,  state  "1",  must  be  completed 
since  it  is  mandatory,  as  reflected  in  the  keyword  data  set  table. 
Therefore,  the  first  entry  to  the  state  table  is  "0,1". 

From  state  "1",  the  TO  set,  state  2,  must  be  completed,  again 
due  to  the  mandatory  condition  set  forth  In  the  keyword  data  set 
table.  State  2  may  be  repeated,  or  state  3,  the  INFO  set,  or  state 
4,  the  CLASS  set  may  be  entered.  No  matter  what  path  is  taken  from 
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;  field  order  is  as  follows: 


presentation  number  of  keyword  data  set 
keyvtord  data  set  name 
state  number 

mandatory  indicator  (m  or  M,  if  mandatory) 
repeatability  irviicator( r  or  R,  if  repeatable) 
version  number  (optional,  blank  will  use  most  recent  version) 
delete  indicator  (l=delete  on  input, ?=delete  on  output, d=delete  on 
input  arvl  output,  blank  or  Caused  for  both  input  and  output) 
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m. 

15, 

almsn, 

15. 

m, 

16. 

61iftscd, 

16, 

m, 

17, 

aknldg, 

17, 

r 

13, 

fiwnqrale, 

13, 

9 

V 


D 


made  repeat ible  by  rev.  1,  TIDP 


Figure  A-8.  Completed  KDS  Table  for  A650  Message 
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state  2,  state  4  must  be  entered.  That  is,  state  4  may  be  entered 
directly  from  state  2,  or  state  3  may  be  entered,  which  forces  the 
next  entry  to  be  state  4.  Therefore,  the  state  tables  preserve  the 
mandatory  condition  by  forcing  an  entry  into  a  particular  field  de¬ 
fined  as  mandatory  by  JINTACCS.  The  state  table  is  completed  in  the 
same  way,  with  the  final  entry  appearing  as  shown  in  figure  A-9. 

Particular  attention  must  be  paid  to  the  descriptive  text  ap¬ 
pearing  in  the  TIDP.  Note  that  from  state  6,  the  EXER  set,  the  next 
entry  that  can  be  made  is  to  state  8,  the  MSGID  set.  An  entry  is 
not  allowed  to  state  7,  the  OPER  set.  This  condition  is  not  re¬ 
flected  in  the  keyword  data  set  table.  In  fact,  if  looking  solely 
at  this  table,  an  entry  from  state  6  into  state  7  looks  valid. 

There  is  also  no  obvious  definition  of  this  exclusiveness  in  the 
table  form  which  appears  in  the  TIDP.  However,  the  EXER  set  does 
appear  flagged  as  being  conditional  in  this  table.  By  looking  at 
the  descriptive  text  in  the  TIDP,  as  shown  in  figure  A-10,  this  ex¬ 
clusiveness  is  definitively  established. 

Group  repeatability  is  a  condition  which  is  not  defined  In  the 
keyword  data  set  table,  but  must  be  established  in  the  state  table. 
The  TIOP  uses  the  left  square  bracket  ([)  to  represent  group  repeat¬ 
ability.  Use  of  the  bracket  indicates  the  beginning  and  ending 
KDS's  that,  as  a  group,  are  repeatable. 

The  APORALOT  message  does  not  allow  any  group  repeatability; 
however,  this  condition  is  reflected  at  its  worst  In  the  Airlift 
Mission  Schedule  (ALMSNSCD)  message,  F631.  The  keyword  data  set 
entry  for  this  message  appears  as  shown  in  figure  A-ll. 
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.state 


0,  1 
1,  2 

2,  2,  3,  4 

3,  3,  4 

4,  5,  6,  7,  8 

5,  6,  7,  8 

6,  8 

7,  8, 

8,  9,10,11 
9,9,10,11 

10,11 

11,12 

12.12.13.14.15.16 

13.14.15.16 

14.14.15.16 

15.16 
16,17,# 

17,  # 


;fron  mandatory 
;to  mandatory 
;to  is  also  repeatable 
;info  is  repeatable 
;class  mandatory 

;choose  either  exer  or  oper 

;msgid  is  mandatory 

;perid  mandatory 
;apor  is  mandatory 
;apor  is  repeatable 

;tgtpri  is  repeatable 

;rmks  mandatory 

;dwngrade  optional  as  result  of  PTR 


Figure  A-9.  State  Table  for  AP0RAL0T  Message 
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UNCLASSIFIED 


J1  NT  ACCS  TIDP-TE 


Volume  VI 
HI 

MESSAGE  INSTRUCTIONS  (U)  Pag*  2  of  A 

MESSAGE  NUMBER:  All  JI NT ACCS  Character-Oriented  Meeaagea  (U) 

Tilth:  Standard  Introductory  Seta  [SIS]  (U) 

SPECIAL  INSTRUCTIONS  (continued)  (U) 

il'l  Set  Identifier:  (CLASS)  [M]  (continued) 

b.  Tor  NATO  aaaaagea.  uae  only  thoae  data  items  end  codes 
listed  under  the  heading  of  "SPECIAL  HANDLING"  (DFI 
#E5B7,  OUT  001). 

>1  ’  Special  Identifier:  SIC  [C].  The  use  of  this  sat  la  mandatory  to 
define  the  subject  matter  of  the  message  when  attached  to  NATO 
command-  This  set  is  not  used  In  Intra-U.S.  messages.  Note  that 
chore  is  no  field  marker  following  the  set  Identifier.  An  end  of 
set  marker  is  not  used  with  this  set. 

ri<-!.:  '.  .  NASIS  Code  [M].  Enter  the  appropriate  NASIS  code  es 

determined  from  NATO  Supplemant  2  to  ACP  121.  (DFI  PE332, 
DU I  001). 

Field  2.  NASIS  Code  |0,h).  The  NASIS  code  field  is  repeated  as 

necessarv  to  describe  the  message  contents  (DFI  fE332,  DUI 

001). 

•T*  Set  Identifier:  EXER  ( C) .  This  set  ie  conditional  upon  the 
message  being  applicable  to  an  exercise.  M|g  MR  la  NU  aaad 

for  oparatloaal  purpueaa  ar  if  an  "BUS"  east  la  Mi. 

Field  1,  Exercise  Nickname  (HJ.  Enter  the  code  name  or  nickname  of 
the  exercise  to  tdilch  the  nessage  pertains  (DFI  IE33S.  DUI 
001). 

Field  2.  Exercise  Message  Additional  Identifier  |0].  Enter  an 

additional  exercise  nickname  or  identifier  (DFI  #E335,  DUI 

002). 

i.i  Set  Identifier:  0PER  [C|.  This  set  is  conditional  upon  the 

message  being  applicable  to  an  operation  that  has  a  code  nan*  or 
nickname.  It  is  not  used  if  an  operation  name  has  not  been 

established,  and  it  la  amt  seal  far  esarelme  pmrpsaaa  ar  if  tha 

set  "EXER"  la  uaad. 

Fte'rt  1.  Operation  Codeword  |M].  Enter  the  assigned  operation  name 
•  »r  nickname  as  established  by  appropriate  authority  (DFI 
*E33h.  DUI  001 i . 


2-lb 


UNCLASSIFIED 


Figure  A-10.  Extract  of  Message  Instructions  from  TIDP 


;  field  order  is  as  follows: 


presentation  nirtoer  of  keyword  data  set 
keyword  data  set  name 
state  nunber 

mandatory  indicator  (m  or  M,  if  mandatory) 
repeatability  indicator (r  or  R,  if  repeatable) 
version  nurfoer  (optional,  blank  will  use  most  recent  version) 
delete  indicator  (l=>delete  on  input,  2*>delete  on  output,  3=delete  on 
input  and  output,  blank  or  0=used  for  both  input  and  output) 


p, 

/ 

KDS,  ST, 

1  t 

M, 

t 

R 

1, 

frcm,  1 , 

m, 

2. 

to,  2, 

m, 

r 

3, 

info,  3, 

» 

r 

4, 

class,  4, 

m. 

5, 

sic,  5, 

» 

6. 

exer,  6. 

» 

7, 

oper,  7, 

8, 

msgid,  8, 

m. 

9. 

ref.  9, 

* 

r 

IP), 

canx ,  IP) , 

i 

11, 

peril,  11, 

m, 

12. 

unable,  12, 

t 

13, 

taskunit,  13, 

m, 

14. 

reqno,  14 , 

m. 

15, 

almsn,  15, 

m. 

16, 

61iftscd,  16, 

m, 

17, 

aknldg,  17, 

i 

18. 

rnks,  18, 

m, 

19. 

dwngrade,  19, 

* 

V.  D 


;  made  repeat ible  by  rev.  1,  TIDP 


Figure  A-ll.  KDS  Table  Entry  for  F631,  ALMSNSCD,  Message 
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According  to  the  TIDP,  the  TASKUNIT  set  through  the  6LIFTSCD 
set  can  be  repeated.  Nested  within  that  repeatability,  the  REQNO 
set  through  6LIFTSCD  may  be  repeated,  and  nested  within  that,  ALMSN 
through  6LIFTSCD  may  be  repeated.  This  Is  represented  In  the  state 
table  pictured  In  figure  A-12.  The  mandatory  conditions  force  con¬ 
tinuation  downward  through  the  states  to  the  6LIFTSCD  set,  state  16. 
From  state  16,  the  TASKUNIT  group,  the  REQNO  group,  or  the  ALMSN 
group  may  be  repeated,  the  AKNLDG  set  or  the  DWNGRADE  set  may  be 
entered,  or  the  message  may  be  terminated. 

The  final  section  of  the  message  description  file  for  the 
APORALOT  message  is  the  table  used  for  prepopulation.  In  order  to 
make  an  entry  to  this  section,  it  is  necessary  to  decide  which  field 
in  a  KDS  is  to  be  prepopulated.  For  example,  the  classification 
field  of  the  CLASS  KOS  Is  prepopulated,  as  is  the  message  type  field 
of  the  MSG 10  KOS  In  all  messages.  The  APORALOT  message  which  will 
be  displayed  by  the  JAMPS  system  will  be  prepopulated  with  a  clas¬ 
sification  of  SECRET  which  is  changeable,  and  a  message  type  of 
APORALOT  which  will  remain  fixed.  The  aporalot  file  is  now  com¬ 
plete  and  appears  as  shown  in  figure  A-13. 

As  mentioned  above,  the  presentation  number  and  the  state  num¬ 
ber  of  a  keyword  data  set  need  not  be  the  same.  In  adding  a  keyword 
data  set  to  the  message,  the  presentation  numbers  of  any  KDS  follow¬ 
ing  the  entry  location  of  the  new  KDS  must  be  changed  accordingly. 

It  is  possible  to  avoid  changing  all  of  the  state  numbers  by  letting 
the  state  number  of  the  new  KOS  be  the  next  sequential  number  In  the 
list. 

Assume,  for  example,  that  during  testing  It  was  discovered  that 
the  CANX  set  had  been  Inadvertently  omitted  from  the  APORALOT  mes¬ 
sage.  The  incorrect  entry  of  A650  Is  pictured  in  figure  A-14.  The 
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.state 

0.  1 
1,  2 

2.  2,  3,  4 

3.  3.  4 

4.  5,  6,  7,  8 

5.  6,  7,  8 

6.  8 

7,  8 

8,  9,10,11 
9,9,10,11 

10,11 

11.12.13 

12.13 

13.14 

14.15 

15.16 

16.13.14.15.17.18 

17.18 
18,19,  # 

19,# 


;from  mandatory 
;to  mandatory 
;to  is  also  repeatable 
;1nfo  is  repeatable 
;class  mandatory 

;choose  either  exer  or  oper 

;msgid  is  mandatory 

;perid  is  mandatory 

;taskunit  is  mandatory 

;reqno  is  mandatory  taskunit  starts  rptbl  group 
;almsn  is  mandatory  reqno  starts  nstd  group 
;61iftscd  is  mandatory  almsn  starts  2nd  nest 
;61iftscd  ends  all  rptable  groups 
;rmks  is  mandatory 

;dwngrade  is  optional  as  result  of  PTR 


Figgis  A- 12.  State  Table  for  F631 


i 


■  msg  a650 
•edition  0 


;  field  order  is  as  follows: 


presentation  ntnber  of  keyword  data  set 
keyword  data  set  name 
state  nutter 

mandatory  indicator  (m  or  M,  if  mandatory) 
repeatability  indicator(r  or  R,  if  repeatable) 
version  mntoer  (optional,  blank  will  use  most  recent  version) 
delete  indicator  (l=delete  on  input, 2-delete  on  output, 3-delete  on 
input  and  output,  blank  or  0*used  for  both  input  and  output) 


p, 

» 

KDS, 

ST,  M,  R,  V, 

1, 

from, 

1,  m,  , 

2, 

to. 

2,  m,  r. 

3, 

info. 

3,  ,  r, 

4, 

class, 

4,  m,  , 

5, 

sic. 

9,  ,  , 

6, 

exer. 

6,  ,  , 

7, 

oper. 

7,  ,  . 

8, 

msgid. 

8,  m,  , 

9, 

ref, 

9,  ,  r, 

10, 

canx, 

17,  ,  , 

11, 

per id. 

10 ,  m. 

12, 

appor, 

11,  m,  r. 

13, 

6a lot, 

12,  ,  , 

14, 

tgtpri. 

13,  ,  r. 

15, 

aknldg. 

14,  ,  , 

16, 

rrnks, 

15,  m,  , 

17, 

d#/ngrade, 

16,  ,  , 

. state 


:  made  repeatible  by  rev.  I,  TIDP 


0,  l 
1,  2 

2,  2,  3,  4 

3,  3,  4 

4,  5,  6,  7,  8 

5,  6,  7,  8 

6,  8 

7,  8, 

8,  9,10,17 
9,9,10,17 

10,11 

11.11.12.13.14.15 

12.13.14.15 

13.13.14.15 

14.15 
15,16,# 

16, « 

17,10 


:frcm  mandatory 
:  to  mandatory 
rto  is  also  repeatable 
: info  is  repeatable 
: class  mandatory 

: choose  either  exer  or  oper 

••rnsgid  is  mandatory 

:  per  id  mandatory 
rapor  is  mandatory 
:apor  is  repeatable 

itgtpri  is  repeatable 

:n*s  mandatory 

rdwngrade  optional  as  result  of  PTR 


;  following  area  is  optional  and  used  for  mandatory  entries  in 
;  certain  fields  of  keyword  data  sets 

:  field  order  is  as  follows 

7  presentation  nuttoer  for  applicable  keyword  data  set 
relative  field  nuttoer  to  which  entry  applies 
r  entry  to  be  inserted  (will  be  used  as  a  character  string) 

:  protection  code  for  data  (p  protected,  u  or  blank  unprotected) 


..nan 

4,l,s  e  c  r  e  t,u  ;claas 
0,l,aporalot,p  ;megld 

Figure  A- 13.  Complete  A650  Entry  to  Data  Base 
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.J**v 


O  2 

e  §• 

Q  " 

o  .9 

if 

►< 

13 


.insq  .16  50 
.edition  0 


field  order  is  as  follows: 


presentation  number  of  Keyword  data  set 
Keyword  'lata  set  name 
state  number 

mandatory  indicator  (m  or  M,  if  mandatory) 

refientabi 1 i ty  indicatorfr  or  R,  if  repeatable) 

version  number  (optional,  blank  will  use  most  recent  version) 


; 

delete  indicator 

(l=delete  on  input, 2=delete  on  output, 3=delete  on 

; 

input 

and 

output 

blanK  or 

?*=used  for  both  input  and  output) 

;  P, 

i  1 

KDS, 

1 

ST, 

M, 

0 

R. 

0 

V,  D 

0 

1 . 

frtn. 

1. 

0 

» 

2, 

to, 

2, 

r. 

1 

3, 

info. 

3, 

$ 

r, 

» 

4. 

class, 

4, 

m, 

0 

0 

5, 

sic. 

s. 

* 

t 

6, 

exer, 

6, 

• 

t 

1 

7. 

oper. 

7, 

1 

0 

0, 

rnsqid. 

8, 

m. 

t 

0 

0, 

ref. 

0, 

» 

r. 

0 

made  repeat ible  by  rev.  1,  TIDP 

10. 

peril. 

10, 

m. 

1 

t 

11. 

appor , 

11  . 

m. 

r. 

0 

12, 

6a 1 ot , 

12. 

• 

1 

0 

13. 

tgtpri, 

13, 

1 

r, 

0 

14. 

aknldq, 

14, 

t 

0 

0 

IS, 

dwrrjrade, 

15, 

$ 

0 

0.  1 
1.  2 

2,  2,  3,  4 

3,  3,  4 

4,  5.  6,  7,  8 

5,  6,  7.  8 

6,  8 

7,  8, 

8,  9,10 
0,9,18 

10,11 

11,11,12 

12.13.14.15, * 

13.13.14.15, * 

14.15, * 

15. « 


?  f ron  mandatory 
;to  mandatory 
:to  is  also  repeatable 
;info  is  repeatable 
:  class  mandatory 

: choose  either  exer  or  oper 

rmsgid  is  mandatory 

r per id  mandatory 
rapor  is  mandatory 
rapor  is  repeatable 

rtgtori  is  repeatable 


Figure  A- 14.  A650  Message  with  CANX  Set  Omitted 
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CANX  set  now  has  to  be  added  to  the  message.  The  keyword  data  set 
table  has  to  be  rewritten  from  the  PERID  set  downward.  Although 
this  is  not  difficult,  It  would  be  if  this  had  been  a  large  message 
with  forty  to  fifty  keyword  data  sets.  In  addition  to  rewriting  the 
keyword  data  set  table,  the  state  table  would  also  have  to  be  re¬ 
written.  A  shortcut  can  be  taken  by  adding  the  CANX  set,  renum¬ 
bering  the  presentation  numbers  and  assigning  a  state  number  of  16 
to  the  CANX  set.  The  new  entry  of  A650  with  the  CANX  set  is  shown 
in  figure  A-15. 

The  next  step  is  to  enter  the  keyword  data  sets  in  kdslndex. 
Since  the  standard  introductory  sets  and  the  JANAP  KDS's  appear  in 
every  message,  there  is  no  need  to  enter  them  Into  the  data  base. 
However,  it  is  advisable  to  verify  that  they  do  appear.  It  will  be 
necessary  to  enter  the  CANX,  PERID,  APPOR,  6AL0T ,  TGTPRI ,  AKNLDG, 
and  DWNGRADE  sets  in  kdslndex. 

Most  of  these  KDS's  appear  as  KDS's  in  other  messages,  in  fact, 
they  may  already  exist  in  the  data  base.  For  this  tutorial,  how¬ 
ever,  the  assumption  is  made  that  they  do  not.  The  keyword  data  set 
name  is  Inserted  In  kdslndex,  preserving  the  alphabetical  order, 
followed  by  the  KDS  index  number.  The  next  sequential  number  Is 
chosen  for  the  6AL0T  KDS,  and  so  on  through  the  list  of  new  KDS’s. 
The  completed  kdslndex  entry  is  shown  in  figure  A-16. 

There  Is  no  KDS  with  an  Index  number  of  12  in  the  kdslndex  file 
as  it  now  appears,  since  It  has  been  deleted.  Deletion  of  the  KDS 
did  not  cause  a  reordering  of  the  KDS  index  numbers.  Also,  while  an 
alphabetical  order  makes  It  easy  to  determine  whether  or  not  a  KDS 
is  in  the  kdslndex,  it  makes  It  very  difficult  to  determine  the  next 
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•  msg  a650 
.edition  0 


field  carder  is  as  follows: 


presentation  number  of  keyvrord  data  set 
keyword  data  set  name 
state  number 

mandatory  indicator  (m  or  M,  if  mandatory) 

repeatability  indicator(r  or  R,  if  repeatable) 

version  nuiber  (optional,  blank  will  use  most  recent  version) 


delete  indicator  (l=delete  on  input, 2=delete  on  output, 3=delete  on 

input  and  output,  blank  or  0=used  for  both  input  and  output) 

p. 

0 

KDS,  ST, 

0  0 

M, 

0 

R,  V,  D  ; 

0  0  * 

1, 

fran,  1 , 

m, 

0  0 

2, 

to,  2, 

m, 

r,  * 

3, 

info,  3, 

# 

r,  0 

4, 

class,  4, 

m, 

0  t 

5, 

sic,  5, 

• 

0  • 

6, 

exer,  6, 

$ 

0  0 

7, 

oper,  7, 

0 

0  0 

a, 

msgid,  8, 

m, 

0  0 

a. 

ref,  9, 

0 

r,  , 

made  repeat ible  by  rev.  1,  TIDP 

10, 

canx,  16, 

0 

0  0 

u, 

per id,  10, 

m, 

0  0 

12, 

appor,  11, 

m. 

r,  , 

13, 

6alot,  12, 

0 

0  0 

14, 

tgtpri,  13, 

0 

1’/  # 

15, 

aknldg ,  14 , 

0 

0  0 

16, 

dwngrade,  15, 

0 

0  0 

-state 


0,  l 
1.  2 

2,  2,  3,  4 

3,  3,  4 

4,  5,  6.  7,  8 

5,  6,  7,  8 

6,  8 

7,  8, 

8,  9,10 
9,9,10,16 

10,11 

11,11,12 

12.13.14.15, # 

13.13.14.15, # 

14.15, * 

15,# 

16,10 


;  f  rcni  mandatory 
;  to  mandatory 
rto  is  also  repeatable 
; info  is  repeatable 
rclass  mandatory 

r choose  either  exer  or  oper 

;msgil  is  mandatory 

; per id  mandatory 
rapor  is  mandatory 
;apor  is  repeatable 

;tgtpri  is  repeatable 

?canx  set  added 


Figure  A- 15.  APORALOT  Entry  with  CANX  Set  Added 
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kds index 


field  order  is  follow*: 

keyword  d*ta  set  nans 
keyvocxS  d*\a  »«et  rxsrtoer 

version  ruetoer  {  blank  Is  interpreted  as  zero  (ft)) 


FROM. 

l 

TO. 

2 

INFO. 

3 

AM>N. 

4 

NARR. 

5 

RMCS, 

6 

CLASS, 

7 

owce, 

192 

CANCEL. 

8 

DELETE, 

9 

AFTER. 

10 

ADD. 

11 

6A UJV, 

193 

6APPDIS, 

13 

AIRBASE, 

66 

AIRDROP, 

67 

AIRSPACE, 

68 

AIRTIXS, 

69 

AKNL/X3, 

194 

ALERT, 

70 

ALMSN, 

71 

ALT, 

72 

APPOR, 

195 

APPROVE, 

73 

ARDAT, 

74 

ARDEFXM, 

75 

BASEST  AT, 

81 

BG'iREF, 

82 

BEACON, 

93 

CANX, 

196 

CAP, 

84 

CATOON, 

95 

CIRCLE, 

86 

DUALDQG, 

99 

DUPTRK, 

100 

DITTIES, 

101 

DWNGRADE, 

197 

BOCAT, 

102 

BOCFF, 

103 

EFFECT  IV, 

104 

OPER, 

141 

ORDAVAIL, 

142 

PEREFF, 

143 

PERID, 

190 

PIRBP, 

144 

PR0TFRB3, 

145 

RCTOOH», 

146 

TCTCDO, 

179 

TOTWfT, 

180 

WHjts, 

181 

TOTPRI, 

199 

TIIWf», 

182 

UNABLZ, 

183 

uxjt,  m 

RBLne,  Iff) 

TW#,  191 

Figure  A- 16.  kdsindtx  with  A650  Sets  Added 
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number  that  should  be  used  as  the  index  number.  However,  alphabeti¬ 
cal  order  is  not  a  system  requirement,  but  a  personal  preference. 
Sequential  ordering  of  the  KDS  index  numbers  is  also  a  personal 
preference;  the  only  requirement  is  that  each  KDS  have  a  unique  KDS 
index  number. 

The  next  entry  is  to  kdss,  and  all  the  information  needed  is 
found  in  the  Catalog  of  Keyword  Data  Sets.  Entries  need  not  be  made 
for  the  standard  introductory  sets  since  they  should  already  exist 
in  kdss;  verifying  that  they  exist  is  sufficient.  Entries  are  made 
in  alphabetical  order. 

The  first  set  to  be  entered  is  the  6AL0T  set.  The  first  entry 
is  ".KDS  6AL0T" ,  followed  by  the  KDS  type.  The  set,  6AL0T ,  is  a 
columnar  set,  as  determined  by  the  numeric  as  the  first  character  in 
the  set  name.  Therefore,  the  next  entry  would  be  ".COLUMNAR",  fol¬ 
lowed  by  ".VERSION  0".  The  field  table  can  now  be  entered. 

The  first  entry  for  the  field  table  preceding  the  actual  tabu¬ 
lar  information  is  ".FIELD".  The  DFI/DUI's  are  then  listed  with  the 
information  as  described  in  paragraph  2.2.2.  Since  6AL0T  is  a 
columnar  set,  the  print  positions  must  be  entered  for  the  fields. 

The  print  positions  can  be  determined  by  looking  at  the  SET  MAP  in 
the  KDS  catalog.  A  warning  should  be  given  at  this  point  that  the 
Catalog  of  Keyword  Data  Sets  has  been  known  to  contain  errors  in  the 
SET  MAP.  This  can  be  checked  by  doing  a  field- by- field  verification 
by  referring  to  the  MED,  or  it  can  later  be  verified  when  a  cross 
check  is  done  against  the  data  base.  Using  the  information  appear¬ 
ing  in  this  table,  the  state  table  can  be  built.  The  entry  to  the 
data  base  for  the  6ASL0T  set  appears  in  figure  A-17. 


.KDS  6ALOT 
■COLUMNAR 
■VERSION  0 


■FIELDS 

FIELD  ORDER  IS  AS  FOLLOWS: 

FIELD  NUMBER 
DFI  NUMBER 
DUI  NUMBER 
STATE  NUMBER 

PRINT  POSITION  FOR  FIELD  HEADER  (ONLY  USED  FOR  TYPE  COLUMNAR) 
MANDATORY  INDICATOR  (M  IF  MANDATORY) 

REPEATABILITY  INDICATOR  (R  IF  REPEATABLE) 

FIELD  DESCRIPTOR  INDICATOR  (1=RB3UIRED,  0  OR  BLANK=NOT  USED) 

DELETE  INDICATOR  (1=DELETE  ON  INPUT,  2=DELETE  ON  OUTPUT,  3=DELETE  ON 
INPUT  AND  OUTPUT,  BLANK  OR  0=USED  FOR  BOTH  INPUT  AND  OUTPUT) 


;  P, 

*  t 

DFI,  DUI, 

*  * 

ST,  PR, 

1  f 

M, 

1. 

EPI987,  031, 

1.  3, 

M 

2, 

30987,  032, 

2,  16, 

M 

3, 

30107 ,  004, 

3.  30, 

M 

4, 

E0031,  022, 

4,  35, 

M 

5, 

30513,  001, 

5,  40, 

6. 

30987,  923, 

6,  47, 

7. 

30527,  001, 

7,  61, 

R.  F,  D 


■STATE 


D.  I 

V,  2 

2.  3 

3.  4 

4.  5,  6,  7,  # 

5.  6,  7,  4 

6.  7,  * 

7.  I 


Figure  A- 17.  Entry  for  6AL0T  KDS  to  kdss 
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Entries  are  now  made  to  kdss  for  the  rest  of  the  KDS's  in 
APORALOT,  as  shown  in  figure  A-18.  In  the  state  table  for  the  APPOR 
KOS,  states  3,  4  and  5  are  repeatable.  However,  in  the  state  table, 
unlike  a  message  state  table,  state  3  can  only  go  to  states  4  or  5, 
not  to  itself.  Unlike  the  repeatability  of  KDS's  within  a  message, 
the  repeatability  of  fields  within  a  KDS  is  treated  as  a  group  re¬ 
peatability.  Also,  according  to  JINTACCS  formatting,  if  field  "n" 
is  repeatable,  all  fields  following  field  "n"  are  also  repeatable. 
This  is  further  defined  as  all  fields  following  field  "n"  are  treat¬ 
ed  as  nested  repeatable  groups.  Therefore,  if  there  are  eight 
fields  within  a  KDS  and  field  5  is  repeatable,  fields  5,  6,  7,  and  8 
are  repeatable  as  a  group,  fields  6,  7  and  8  are  repeatable  by  them¬ 
selves. 

In  building  the  state  table  for  fields  within  the  KDS,  care 
must  be  exercised  to  avoid  confusing  the  state  numbers  with  the 
field  numbers.  For  ex  nple,  in  the  AEW  KDS,  as  shown  in  figure 
A-19,  states  3  and  4  are  alternate  contents  fields  for  field  3, 
states  5  and  6  are  alternate  contents  fields  for  field  4,  and  states 
7,  8,  and  9  are  alternate  contents  fields  for  field  5.  In  the  AEW 
state  table,  state  ?.  can  go  to  state  3  or  state  4.  Although  state  3 
is  mandatory,  it  is  only  one  of  the  possible  alternative  fields  that 
may  be  entered. 

Upon  completion  of  the  entry  to  the  kdss  file,  the  next  entry 
is  to  be  file  dfidui.  Again  it  is  assumed  that  no  entries  for  this 
message  have  been  previously  entered  to  this  file  except  for  the 
fields  comprising  the  standard  introductory  sets.  To  make  entries 
to  dfidui,  the  MED  is  the  necessary  documentation. 


.KDS  AEW 
.LINEAR 
.VERSION  0 


.FIELDS 

1,  30500,  015, 

2,  30491,  006, 

3,  33651,  002, 

3,  30681,  002, 

4,  33651,  003, 

4,  30681,  003, 

5,  00469,  008, 
5,  00497,  005, 
5,  00498,  002, 


1,  ,  M,  , 

2,  ,  ,  ,  1 

3,  ,  M,  , 

4,  ,  M,  , 

5,  ,  M,  , 

6,  ,  M,  , 

7,  ,  M,  R, 

8,  ,  M,  R, 

9,  ,  M,  R, 


•STATE 

0,  1, 

1,  2,  3,  4, 

2,  3,  4, 

3,  5,  6, 

4,  5,  6, 

5,  7,  8,  9, 

6,  7,  8,  9, 

7,  7,  8,  9,  #, 

8,  7,  8,  9,  #, 

9,  7,  9,  9,  #, 


Figure  A- 19.  AEW  Keyword  Data  Set 


Excluding  the  standard  Introductory  sets,  the  seven  remaining 
KDS's,  CANX,  AKNLDG ,  APPOR,  CANX,  DWNGRADE,  PER ID  and  TGTPRI,  break 
down  into  28  DFI/DUI's  (26  unique  DFI/DUI's).  The  following  DFI/ 
DUI's  must  be  entered  into  dfldul:  E0019  001,  E0027  016,  E0031  017, 
E0031  022,  E0050  001,  E0107  004,  C0143  005,  C0143  006,  C0143  007, 

E0146  001,  E0147  001,  C0183  001,  E0319  003,  E0332  002,  E0513  001, 

E0527  001,  E0580  001,  E0679  001,  E0908  002,  E0922  002,  E0939  001, 

E0987  018,  E0987  023,  E0987  031,  E0987  032  and  E1042  001. 

In  making  an  initial  entry  of  a  DFI  Into  dfldul,  the  MED  must 
be  consulted  to  determine  the  DFI  type:  "com",  "dlf"  or  "chn".  All 
the  DUI's  associated  with  a  DFI  must  be  compared  against  each  other 
to  see  If  there  are  any  variances  of  minimum  or  maximum  field  size, 
left/right  justification,  or  In  message  map  characters. 

The  first  entry  to  be  made  to  dfldul  Is  for  E0019  001.  By  con¬ 
sulting  the  MED,  It  is  determined  that  all  DUI's  have  the  same  field 
size,  message  map  characters,  and  justification.  Therefore,  we  have 
a  "com"-type  DFI.  The  entry  for  a  "com"-type  DFI  Is  ".com",  follow¬ 
ed  by  "e"  or  "c"  and  the  DFI  number,  left/ right  justification  flag, 
fixed/variable  length  flag,  minimum  field  length,  maximum  field 
length  and  the  message  map  codes.  Therefore,  the  first  entry  Is: 

.com  e0019,l ,v,2,6,a 

The  next  entry  Is  for  E0027  016.  This  Is  a  "dif'-type  DFI, 
since  OUI  001  through  004  are  codes  of  one  to  three  numerics,  and 
DU I  007  and  016  are  codes  of  one  or  two  numerics.  The  entry  for  a 
"d1f"-type  DFI  Is  ".dlf",  followed  by  "e"  or  "c"  and  the  DFI  number. 
This  Is  followed  by  ".dul",  the  DUI  number,  the  left/right  justi¬ 
fication  flag,  fixed/variable  length  flag,  minimum  field  length. 
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maximum  field  length,  and  the  message  map  characters,  separated  by 
commas.  The  entry  for  E0027  016  Is  the  following: 

.dif  e0027 

.dui  016,r,v,l ,2,n 

The  third  possible  type  of  entry  to  make  to  dfldul  Is  for  a 
'‘chn"-type  DFI.  The  entry  for  C0143  006  Is  this  type.  The  entries 
for  C0143  006  and  C0143  007  are  Identical  to  C0143  005.  There  Is  no 
differentiation  between  OUI's  In  "chn"-type  DFI's.  The  entry  for 
C0143  005  Is  In  the  same  format  as  the  ".com",  except  that  It  is 
followed  by  a  list  of  the  component  parts  of  the  chain  by  DFI /DUI. 
The  entry  for  C0143  005  is  the  following: 

.chn  c0143,l ,f , ,7,nnnnna 
.chain 

e0023 ,001 
e0024,001 
e0025,001 
e0026,001 

The  remaining  entries  to  dfldul  are  shown  In  figure  A-20.  The 
entry  for  C0183  Is  not  shown.  This  field,  as  It  appears  In  the  MED, 
Is  contrary  to  JINTACCS  rules.  To  avoid  confusion,  it  was  omitted 
from  this  tutorial  as  a  future  revision  to  the  MED  will  correct  this 
error.  Note  that  In  making  the  entries  of  E0031  017  and  E0031  022, 
the  entries  were  simply  added  to  the  list  already  existing  in  the 
data  base.  Also  note  that  the  entry  of  C0143,  a  chain- type  DFI, 
requires  the  entry  of  all  the  component  parts  of  the  chain,  thus, 
E0023  001,  E0024  001,  E0025  001  and  E0026  001  have  been  added. 
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.con  «0023,r.f,,2,n 


<iif  00*124 
•4ui  Wl.r,  f,  ,2,n 

dif  00025 
.'Vn  001,  r,f.  ,2.n 

dif  00026 

•'tui  00I,l.f,,l,o 

4lf  40031 

.*n  001  ,r. v, l ,4,ruiox 


tin  017,r,v#l ,4,nxxx 
•  tui  022, r,v,  1,1, n 


. tm  009. r.v, 1 , l.n 
Ku  I00,r,v,l. l.n 

Uf 

■  tm  001,  l.v.1,20,* 
Vn  002, 1,v,  1  ,?0,« 

Ilf  4U0T 

-  tm  001  ,  l ,  v,  2,4.0 


tin  004. 1  ,v.?,4.ft 


t»n  04B.  l.v.2.5,4 


00146.1 ,v, 1,20.« 
o014?,r.v,  1 ,7,n 


.iin  00) n  1 .  f .  ,l,o 

00112,  l.f.  .).o 

Ilf  0*1  1 

Vn  00l.l.v.2.6.« 

»■"  0)427.  l .  */,4.6.o 

•*»"  *0500.  I  .  f  .  ,  I  ,  * 


Ilf  0*74 

tm  001  .  I  .  v.  I  .  25 . ««n 


frci*  rham  typo  In  0ov  I 


♦...  001 . 1  v.  »,  V 
V« i  002 ,  i.v,  I,  V 
Vn  00),  i .  v.  j. 


'0N.  V)  Sm  l.f..). 


72.  i . 

.  I  ■ 


Ilf  01 
lui 


tw»  4|4.  J  .  *  .  .  I  4  # 


Vn  0|*,l.  o,l.  ll.o 
Vji  011.  |.w.  II).* 

■■Vi i  41J.l  v.  I  .11.* 

0U)  01T.I.V.I  .  M.* 

■'»  #1042. 1 ,  ( ,  .V* 

Flguro  A-20.  L..try  of  MO0M.OT  OFCs  to  tfttrt 
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The  next  entry  for  these  fields  Is  to  the  fdfh  file.  This  file 
consists  of  the  entry  of  the  DFI  and  DUI  numbers,  followed  by  the 
field  descriptor  and  field  header.  The  Information  to  be  entered 
can  be  gathered  from  the  f€D  and/or  the  Catalog  of  Keyword  Data 
Sets.  The  field  descriptor  and  field  header  follow  one  right  under 
the  other  In  the  MED  under  the  column  "FLD  DESC/COL  HEADER".  The 
field  descriptors  and  field  headers  may  also  be  determined  from  the 
Catalog  of  Keyword  Data  Sets  by  seeing  If  they  are  displayed  In  the 
SET  MAP  area.  An  entry  must  be  made  to  this  table  only  If  the  field 
can  appear  by  Itself;  l.e..  It  can  exist  outside  a  chain.  The  en¬ 
tries  to  be  made  to  fdfh  for  the  APORALOT  message  appear  In  figure 
A-21.  A  field  descriptor  must  be  entered  In  dfldul  for  each  DFI/ 

DUI.  A  field  header  need  only  be  entered  If  the  DFI/DUI  appears  as 
part  of  a  columnar  keyword  data  set.  If  there  Is  no  entry  for  field 
descriptor  or  field  header  In  the  MED,  an  entry  which  appropriately 
captured  the  essence  of  the  field  was  made  up  and  entered. 

The  next  entries  are  to  the  codes,  helptext,  and  Iteacodes 
files.  Since  these  are  almost  direct  copies  from  the  MED,  there  Is 
no  need  to  go  Into  great  detail. 

Entries  are  made  to  codes  and  Iteacodes  by  entering  an  "E"  or  a 
"C",  followed  by  the  DFI  number  and  the  DUI  number.  The  DFI  number 
Is  expected  to  be  a  four-digit  number,  but  the  first  leading  zero 
may  be  entered  as  a  blank.  The  DUI  number  follows  Immediately,  with 
no  separation.  The  entry  for  a  "C"-type  DFI  Is  simply  the  pre¬ 
ceding:  the  DFI  and  OUI  numbers  and  DUI  name.  No  additional  text 
follows  this  entry  for  a  "C"-type  DFI.  An  "E"-type  DFI  Is  followed 
by  copying  what  appears  In  the  DATA  ITEM  column  of  the  I^D,  and  the 
entry  In  the  CHAR  CODE  section  of  the  MED,  delimited  by  asterisks. 
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e0019,  001, tgttyp, tgttyp 
e0023,  002 , cdday , cdday 
e00 27,  016,asgn,asgn 
e0031,  017,asgn,asgn 
e0031,  022,noac,noac 
e0050,  001,msg-title 
e0107,  004,amsn,amsn 
C0143,  005, date- time- ref 
C0143,  006 , from, from 
C0143,  007, to, to 
e0146,  001,msg-orig 
e0147,  001 ,msg-ser-nur> 
e0319,  003 , aknreq, aknreq 
e0332,  002,sjc 
e0513,  001 , aotyp, actyp 
e0527,  001 , icao, icao 
e0580,  001  ,nnthm 
e0679,  001 .dwngrade 
60908,  002 , gentyp , gentyp 
60922,  001,per-or-nun 
e0939,  001 ,msn,msn 
e0987  ,  018,qtyand,cnpOTd 
e0 987,  023,acuntid,acuntid 
e0987,  031, lose, lose 
e0987,  032, gain, gain 
el042,  001 , spec- not 


;arribiguous  spec  of  fd  or  fh 
;no  field  descriptor  in  W35 

;no  field  descriptor  in  MED 
;no  field  descriptor  in  Ef35 

;no  field  descriptor  in  MED 

; ambiguous  spec  of  fd  or  fh 
;amibguou8  spec  of  fd  or  fh 

;no  field  descriptor  in  MED 

;no  field  descriptor  in  MED 


Figure  A-21.  Entries  to  fdfh 
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Figure  A-22  shows  part  of  the  entry  for  the  APORALOT  message  to 
the  codes  file.  The  identical  entry  could  be  made  to  the  Itemcodes 
file,  however,  some  changes  may  be  desired  for  esthetic  purposes. 

For  example,  in  the  entry  for  E0050  001,  the  code  used  for  Helicop¬ 
ter  Dally  Mission  Summary  Is  HELODLYMSNSUM.  This  code  spans  two 
lines,  and  will  be  concatenated  in  the  processing  of  the  codes  file. 
The  codes  file  is  used  for  Internal  purposes  only;  the  operator  will 
never  see  it.  The  Itemcodes  file,  on  the  other  hand,  is  displayed 
to  the  operator.  Therefore,  the  entry  for  HELODLYMSNSUM  code  and 
similar  codes  may  be  displayed  as  shown  in  figure  A-23,  rather  than 
using  the  same  convention  as  is  the  codes  file. 

Figure  A-24  shows  parts  of  an  entry  of  E0515  001  to  the  codes 
file  and  the  concatenation  symbols  used.  This  entry  contains  a  num¬ 
ber  of  examples  where  codes  span  more  than  one  line.  The  sharp 
sign,  "#",  is  used  in  processing  this  file  to  show  that  a  space 
should  be  left  between  the  two  sections  of  the  codes  being  concaten¬ 
ated.  The  equal  sign,  "=",  is  used  to  represent  a  hyphen  which  will 
be  deleted  by  the  processor  upon  concatenation  of  the  two  sections. 
If  there  is  no  symbol  between  the  two  sections,  upon  processing,  a 
simple  concatenation  of  the  two  sections  will  take  place.  These 
concatenation  symbols  do  not  appear  in  the  Itemcodes  file. 

Entries  to  the  helptext  file  are  made  as  specified  in  paragraph 
2.4.1.  A  portion  of  the  entry  for  the  APORALOT  message  Is  shown  In 
figure  A-25.  The  definition  is  taken  from  the  MED  entry  for  the  DUI 
explanation.  When  necessary,  the  explanation  should  be  rewritten  to 
provide  a  clear,  concise  and  easily  understood  definition  of  the 
OUI.  The  instruction  portion  should  provide  Information  to  the  op¬ 
erator  on  how  Information  should  be  entered  into  a  field.  For  a 
"C"-type  DFI,  Information  for  entering  each  "E"-type  DFI  which  com¬ 
prises  the  chain  must  be  embedded  in  the  Instructions  for  the  chain. 
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5  019001  TARGET  TYPE 


* 

ASSEMBLY  AREAS 

*  ASSY 

* 

* 

BRIDGE 

*  BRIDGE 

* 

* 

BUILDING 

*  BLDG 

* 

* 

OGMWM  CENTER 

*  CMJCTR 

* 

* 

CDMUNICATIONS/ 

*  OOMELT 

* 

* 

ELECTRONICS 

* 

* 

* 

DAM 

*  DAM 

* 

* 

DROP  ZONE 

*  DROPZN 

* 

* 

FORTI FICATION/STHJCP  JRE 

*  TFOFfT 

* 

* 

ANTIRADIATION  MISSILE 

*  ARM 

* 

(ARM) 

* 

* 

ESM  AIRCRAFT  PERFORMING 

*  ESMAIR 

* 

BCM  DECEPTION 

* 

* 

ESM  SURFACE  JAMMER 

*  ESMSUR 

* 

1-X71  SURFACE 

*  EXXSUR 

* 

BCM  AIRCRAFT  JAMMER 

*  BCMAIR 

E  023001  DAY 

* 

(01 

*  (01 

* 

THRU 

*  THFU 

* 

31) 

*  31) 

E 

026001  TIME  ZONE 

* 

artr  puis  i  hour 

*  A 

* 

cmt  puis  2  hours 

*  B 

* 

CMT  PUIS  3  HOURS 

*  C 

* 

OTT  MINUS  3  HOURS 

*  P 

* 

* 

0ir  MINUS  2  HOURS 

*  O 

* 

* 

CMT  MINUS  1  HOUR 

*  N 

* 

* 

GREFNWICH  MEAN  TIME 

*  Z 

* 

* 

(GW) 

* 

* 

E  0S0001  MESSAGE  TITLE 

* 

ACKNOWLEDGE  MESSAGE 

*  AKNLDG 

* 

* 

AIR  DEFENSE  COMMAND 

*  AIRDEPCJOM 

* 

* 

MESSAGE 

* 

* 

* 

AIR  DEFENSE  WARNING 

*  AIRDEFWARN 

* 

* 

MESSAGE 

* 

* 

* 

HELICOPTER  AVAILABILITY 

*  HELOAVIL 

* 

♦ 

HELICOPTER  DAILY  MISSION 

*  HELOOLYMSN 

* 

* 

SUMftRY 

*  SUM 

* 

* 

WARNING  ORDER 

*  WARNORD 

* 

* 

WEATOER  FORECAST 

*  WXFCST 

* 

* 

WEARIER  REPORT 

*  VeCRPT 

* 

C  143<W6  FROM 

C  143007  TO 


Figure  A-22.  Partial  Entry  of  OFI's  from  APORALOT  to  codes 


119 


t 


w  * 


05<W01  MESSAGE  TITLE 

ACKNOWLEDGE  MESSAGE 
AIR  DEFENSE  GONMAND 
MESSAGE 

AIR  DEFENSE  WARNING 
MESSAGE 

AIR  EMPLGAfMENT/ ALLOCA¬ 
TION  PLAN 


*  AKNLDG  * 

*  AIRDEFOOM  * 

*  * 

*  AIRDEFWARN  * 

*  * 

*  EMPLOYALOC  * 

*  * 


HELICOPTER  DAILY  MISSION  *  HELODLYMSNSUM  * 
SUNMARY  *  * 


Figure  A-23.  Change  in  HELODLYMSNSUM  Code  for  Iteacode 
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w  * 


515001  POINT  TYPE 


* 

EEM  FIX 

* 

ECM  FIX 

* 

* 

HAZARD 

* 

HAZARD 

dr 

♦ 

HAZARD, 

NAV 

* 

NAV 

* 

* 

HAZARD, 

MINE 

* 

MINE 

* 

dr 

HAZARD, 

IMPACT  POINT 

* 

IMPACT  POINT 

* 

dr 

HAZARD, 

GROUND  ZERO 

* 

GROUND  ZERO 

* 

* 

HAZARD, 

MR/ WEAPON  ENTRY 

* 

MR  WEAPON# 

* 

* 

POINT 

* 

ENTRY  POINT 

* 

dr 

HAZARD, 

MISSILE  LAUNCH 

* 

LAUNCH  POINT 

dr 

dr 

POINT 

dr 

* 

* 

HAZARD, 

ECM  DECOY 

dr 

ECM  DEOOY 

* 

* 

GENERAL 

REFERENCE  POINT 

dr 

GENERAL  REF= 

* 

* 

dr 

ERENCE  POINT 

* 

dr 

MARSHAL 

POINT 

dr 

MARSHAL# 

* 

* 

* 

POINT 

* 

* 

WAY  POINT 

dr 

WAY  POINT 

* 

* 

TOC 

*  TOC 

* 

* 

TDS 

*  TDS 

dr 

dr 

STRIKE  HOSTILE 

*  STRIKE  HOS= 

* 

dr 

*  TILE 

dr 

dr 

tfOSTILE  TROOP  CONCEN¬ 

*  TROOP  OON= 

dr 

dr 

TRATION 

*  CENTRATION 

dr 

★ 

HOSTILE  MRBASE 

*  HOSTILE# 

♦ 

* 

*  MRBASE 

♦ 

dr 

HOSTILE  SAM  SITE 

*  HOSTILE  SAM# 

* 

* 

*  SITE 

* 

* 

HOSTILE  ARTILLERY 

*  HOSTILE# 

* 

*  ARTILLERY 

dr 

HOSTILE  CONVOY 

*  HOSTILE# 

* 

*  CONVOY 

* 

HOSTILE  RML 

*  HOSTILE  RML 

* 

HOSTILE  BRIDGE 

*  HOSTILE# 

dr 

*  BRIDGE 

Figure  A-24.  E0515  001  Entry  to  codes  Showing  Concatenation  Symbols 


1 


•  DPI 

[-:  019001 

T ARGET  TYPE 

DEFINITION:  A  DESCRIPTOR  USED  TO  CLASSIFY  TARGETS  INTO  ONE  OF  SEVERAL 
CLASSES,  CATEGORIES,  OR  GENERIC  GROUPINGS. 

EJ7TER  ONE  OF  THE  COOES. 

.DFI 

E  023001 
DAY 

DEFINITION:  ONE  OF  THE  24  FOUR  PERIODS  OF  A  fOWH  AS  DEFINE)  BY  THE  GREGORIAN 
CALENDAR. 


ENTER  WE  DAY  OF  WE  KWltl. 

.DFI 

E  026001 
TIM  ZONE 

DEFINITION:  ONE  OF  THE  24  TIM  ZONES  INTO  WHICH  THE  WORLD  HAS  BEEN  DIVIDED 
FOR  ESTABLISHING  TIMS  RELATIONSHIPS  BETWEEN  GDDGRAPHICAL  AREAS,  BASED 
UPON  TIE  LOCAL  STANDARD  TIM,  GREENWIOL  ENGLAND  (GMT). 

ENTER  ONE  OF  THE  ODDES. 

.DFI 

031022 

NIMBER  OF  AIRCRAFT 
DEFINITION: 

ENTER  WE  NUMBER  OF  AIRCRAFT. 

.DFI 

•  0*50001 
MESSAGE  TITLE 

DEFINITION:  WE  TITLE  OF  A  MESSAGE/ REPORT . 

FT7TER  O IE  OF  THE  CODES. 

.DPI 

C  143006 
FROM 

DEFINITION:  BOG  INNING  OF  RELEVANT  PERIOD. 

WIS  is  A  0OMPLF7TE  TIM:  lOTW: 

281S55T 

fitter  the  following  sequence  of  characters  and  nlmbers: 


1. 

DAY  OF  THE  fCNW 

(01-31 ) 

2. 

HOUR  OF  THE  DAY 

(00-24) 

3. 

MINlfTE  OF  THE  HOUR 

(00-60) 

• 

4. 

TIM  ZONE 

(A-Z  "WITTING  .1) 

.DFI 

C  143007 
TO 


DEFINITION:  END  OF  RELEVANT  PERIOD. 

THIS  IS  A  COMPLETE  TIM  tt/TR Y: 

2815S5T 

FITTER  WE  PXIOWING  S0QUEJCE  OF  CHARACTERS  AND  NUMBERS: 


l. 

DAY  OF  THE  M>TW 

(01-31) 

2. 

HOUR  OF  THE  DAY 

(00-24) 

3. 

MINUTE  OF  THE  HOUR 

(00-60) 

4. 

TIM  ZONE 

(A-Z  '■WITTING  .1) 

Figure  A-25.  Entries  to  helptext  File  for  A650  Message 
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All  actions  have  now  been  completed  for  entering  the  APORALOT 
message  into  the  data  base.  At  this  point,  the  cross  check  program 
should  be  run  to  ensure  that  nothing  has  been  overlooked  and  to 
verify  the  accuracy  of  the  entries. 
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GLOSSARY 


Terms 

Data  Field  Identifier  A  JINTACCS  term  for  what  is  commonly 

called  a  data  element.  A  data  element 
consists  of  a  definition  of  the  concept, 
a  set  of  data  items  each  identifying  a 
possible  status,  and  the  data  codes  used 
to  represent  the  data  item  in  JINTACCS 
messages. 

Data  Item  A  data  item  identifies  a  discrete  possi¬ 

ble  status  (value)  of  a  DFI  (concept). 

Data  Item  Code  A  data  item  code  is  a  set  of  one  or  more 

alphabetic,  numeric  and/or  special  sym¬ 
bols  taking  the  form  of  a  word  or  words, 
a  code,  an  alphanumeric  serial  number, 
etc.  A  character  code  may  or  may  not  be 
identical  to  its  data  item. 

Data  Use  Identifier  A  data  use  identifier  Is  a  subcategory  of 

a  data  field  Identifier  which  specifies  a 
particular  usage  for  the  concept  defined 
for  the  data  field  identifier. 
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GLOSSARY  (Continued) 


Field  Descriptor  Field  descriptors  are  words,  abbrevia¬ 

tions  or  acronyms  which  describe  or 
amplify  the  data  in  formatted  fields  of 
linear  data  sets. 

Field  Header  Field  headers  are  words,  abbreviations  or 

acronyms  which  describe  or  amplify  the 
data  in  the  columns  of  a  columnar  keyword 
data  set. 

Keyword  Data  Set  A  keyword  data  set  is  an  ordered  collec¬ 

tion  of  data  presented  in  either  a  hori¬ 
zontal  form  or  columnar  form.  See  linear 
keyword  data  set,  columnar  keyword  data 
set  and  free  text  keyword  data  set. 

Linear  Keyword  Data  Set  A  linear  data  set  is  an  ordered  collec¬ 
tion  of  data  fields  presented  in  a  hori¬ 
zontal  manner. 

Columnar  Keyword  Data  Set  A  columnar  keyword  data  set  is  an  ordered 

collection  of  data  fields  aligned  verti¬ 
cally  under  a  horizontal  array  of  field 
headers. 
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GLOSSARY  (Continued) 


Free  Text  Keyword  Data  Set  A  free  text  keyword  data  set  Is  a  free 

text  statement  of  variable  length  bounded 
by  Its  keyword  data  set  name  and  the  set 
terminator  mark  of 


Abbreviations 

altchn  A  JINTACS  DFI  that  is  defined  as  a  con- 

cantenatlon  of  a  variable  number  of 
non-CHN  DFI's  where  the  first  such  DFI's 
value  dictates  which  of  several  possible 
combinations  of  other  DFI's  will  follow 
It 

AUTODIN  Automatic  Digital  Network 


BNF  Backus  Naur  Format 

C  C  is  the  programming  language  used  to 

develop  the  ITSME  software 

CAFMS  Computer  Aided  Force  Management  System 


Chain  DFI  A  JINTACCS  DFI  that  Is  defined  as  a 

concatenation  of  a  fixed  number  of 
non-CHN  DFI's  in  a  fixed  order 
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GLOSSARY  (Continued) 


COM 

COMNOTA8 


COMTAB 


OICP 

OIF 


OIFTAB 


Character  Oriented  Message 

A  JINTACCS  DFI  whose  data  use  identifiers 
all  utilize  a  common  set  of  data  Item 
codes.  In  addition,  no  table  of  values 
Is  supplied  In  the  JINTACS  MED 

A  JINTACCS  DFI  whose  data  use  identifiers 
all  utilize  a  common  set  of  data  item 
codes  and  In  addition  the  JINTACCS  MED 
supplied  a  table  of  legal  values 

Developmental  Interface  Change  Proposal 

A  JINTACCS  DFI  whose  data  use  identifiers 
use  two  or  more  sets  of  different  data 
Item  codes  some  of  which  have  a  table  of 
legal  values  In  the  JINTACCS  MED,  others 
of  which  do  not 

A  JINTACCS  DFI  whose  data  use  identifiers 
use  two  or  more  sets  of  different  data 
Item  codes,  all  of  which  have  a  table  of 
legal  values  specified  in  the  JINTACCS 
MED 
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OIFNOTAB 

DF1 

DUI 

FDFH 

IBLD 

ITSME 

JAMPS 

JANAP  128(H) 
J I NT ACCS 


GLOSSARY  (Continued) 


A  JINTACCS  DFI  whose  data  use  identifiers 
use  two  or  more  sets  of  different  data 
item  codes,  none  of  which  have  a  table  of 
legal  values  specified  in  the  JINTACCS 
MED 

Data  Field  Identifier 

Data  Use  Identifier 

Field  Descriptor  and  Field  Header 

ITSME  data  table  build  program,  the 
executable  name  of  the  program  described 
in  this  specification 

Interoperability  Through  Structured 
Message  Exchange 

JINTACCS  Automated  Message  Preparation 
System 

AUTODIN  Operating  Procedures 

Joint  Interoperability  of  Tactical 
Command  and  Control  Systems 


GLOSSARY  (Continued) 


JOMPSS 

JINTACCS  Oriented  Message  Processing 
Support  Software 

KDS 

Keyword  Data  Set 

MED 

Message  Element  Dictionary 

MSG 

Message 

Opfac 

Operational  Facility 

PLA 

Plain  Language  Address 

PTU 

Participating  Test  Unit 

PWB/UNIX 

PWB/UNIX  Is  the  operating  system  used  to 
develop  the  ITSME  software  and  It  Is  a 
Trademark/Service  Mark  of  the  Bell  Sys¬ 
tem.  PWB  stands  for  Programmers  Work 

Bench 

TIDP 

Technical  Interface  Design  Plan 

UNIX 

UNIX  Is  a  Trademark/Service  Mark  of  the 
Bell  system 
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